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CHAPTER  I 

INTRODUCTION 

Program  testing  has  been  practiced  as  long  as  has 
programming  itself,  in  spite  o£  the  general  confession  that 
testing  can  never  prove  in  any  absolute  sense  that  a  program 
is  correct.  Two  £acts  are  responsible  for  the  popularity  of 
testing.  The  first  is  that  testing  has  a  tendency  to 
uncover  program  errors,  and  that  the  more  systematic  the 
testing,  the  stronger  this  tendency.  The  second  is  that  a 
program  that  is  not  completely  correct  is  not  necessarily 
unreliable  in  a  given  operating  environment,  and  that  even  a 
program  that  is  not  completely  reliable  will  usually  not  be 
completely  worthless  to  its  users.  Those  responsible  for 
software  system  development  are  charged  with  deciding  how 
much  they  are  willing  to  pay  for  a  given  increase  in 
reliability.  The  challenge  for  research  is  therefore  to 
produce  a  testing  method  that  is  (1)  more  effective  at 
uncovering  errors  and  (2)  less  expensive  to  apply.  Nutation 
analysis  has  been  put  forward  as  such  a  method  [1,11,12,5]. 
Working  mutation  systems  have  demonstrated  that  mutation 
analysis  can  be  performed  at  an  attractive  cost  on  realistic 
programs.  (See  Appendices  A-D.)  In  this  work,  the 
effectiveness  of  the  method  is  studied  by  experiments  with 
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programs  in  the  target  application  spaces.  Most  of  our 
target  programs  are  in  Cobol.  Cobol  was  chosen  as  a 
language  of  study  for  several  reasons.  A  pilot  system  had 
already  been  implemented  for  Fortran  [5,11],  and  preliminary 
results  on  testing  small  numerical  subroutines  were 
encouraging.  A  more  complete  Fortran  system  was  being 
developed  concurrently  with  the  development  of  the  Cobol 
system  on  which  this  work  is  based.  We  were  interested  in 
knowing  if  the  mutation  concept  would  be  as  useful  in  a 
language  like  Cobol  as  it  had  been  in  Fortran,  with  Cobol’ s 
different  concepts  of  data  structures,  and  with  input  and 
output,  which  had  never  been  included  in  the  Fortran 
systems,  [lg]  For  a  description  of  the  Cobol  system  and  its 
treatment  of  the  data  division  and  input  and  output,  see 
Appendix  A.  We  were  also  interested  in  a  system  that  would 
allow  us  to  collect  empirical  data  on  programming  and 
testing  practice  and  effectiveness.  Since  Cobol  is  widely 
used,  many  programs  are  available  for  study.  Since 
programming  in  Cobol  is  often  done  under  strict 
regimentation,  it  was  expected  that  we  can  obtain  complete 
packages  consisting  of  programs  along  with  their  test  data 
and  error  histories. 

Software  system  development  has  been  described  in  [22] 
as  a  sequence  of  steps  leading  from  problem  definition  to 
software,  with  corresponding  validation  tasks  relating  the 
result  of  each  step  to  previous  steps.  The  major  steps  are 

f  ■ 
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(1)  System  requirements  definition 

(2)  System  functional  specifications 

(3)  Software  requirements  definition 
(4}  Software  functional  specifications 
(5)  Software  implementation 

The  mutation  analysis  methodology  examined  in  this 
work  has  as  its  goal  validation  of  the  last  stage,  software 
implementation.  As  such  it  overlaps  some  proposed 
validation  methods,  and  complements  others.  The  following 
sections  outline  some  of  these  techniques. 

Automated  Aids  for  Software  Validation 

The  present  work  deals  with  mutation  analysis,  which 
is  an  automated  aid  for  software  validation.  It  is  useful 
to  survey  several  such  aids  designed  for  related  purposes. 
All  of  these  tools  have  as  their  goal  an  increase  in 
confidence  that  a  given  software  product  will  function  as 
desired  under  normal  operating  conditions. 

Static  Code  Examination  Tools. 

The  software  can  be  examined  statically  {without  execution) 
for  some  types  of  errors. 

Syntax  Checkers  -  Compilers.  The  use  of  a  compiler  to 
detect  syntax  errors  is  so  common  that  we  usually  do  not 
think  of  it  as  a  validation  tool.  The  errors  that  are 
detectable  by  a  simple  syntax  check  are  usually  limited  to 


those  such  as  the  use  of  a  variable  of  one  type  where 
another  type  is  required ,  or  the  misspelling  of  a  variable 
name,  resulting  in  an  undeclared  variable,  or  parameter 


mismatch  in  subroutine  calls  [34].  Languages  such  as 
Fortran  that  permit  implicitly  declared  variables  and 
separate  subroutine  compilation  restrict  the  amount  of 
error-detection  that  a  compiler  can  do. 

Standards  Enforcers.  Some  Fortran  compilers  can  be 
invoiced  with  optional  parameters  that  force  the  compiler  to 
treat  undeclared  variables  as  errors  [28].  This  is  an 
example  of  the  use  of  automatic  verification  of 
extra-syntactic  rules  called  standards  that  are  thought  to 
be  useful  in  avoiding  the  introduction  of  errors  into 
software  in  the  first  place.  These  standards  may  have  the 
form  of  additional  syntax  rules  (e.g.  all  variables  must  be 
declared)  ,  the  deletion  of  otherwise  legal  program 
constructs  (e.g.  ALTER  or  GOTO),  or  naming  or  documentation 
conventions . 

Structural  Analysis.  A  more  sophisticated  form  af 
static  analysis  can  give  some  Information  about  the  dynamic 
behavior  of  a  piece  of  software.  Structural  analysis  by  a 
system  such  as  DAVE  [24,25]  can  produce  diagnoses  such  as 


(1)  The  variable  X  is  referenced  before  it  is 
defined  along  all  flows  of  control  in  the  module. 
(Always  indicates  an  error.) 


(2)  The  variable  X  is  referenced  before  it  is 
defined  along  some  flows  of  control  in  the  module. 
(Indicates  an  error,  if  any  of  those  control  paths 
are  actually  executable.) 

(3)  The  variable  X  is  defined  but  not  later 
referenced  along  any  control  path.  (This 
indicates  an  inefficiency,  at  best,  and  more 
likely  a  design  flaw.) 


The  Path  Analysis  strategy  studied  by  Howden  [16]  is 
an  attempt  to  partition  test  cases  into  domains,  each  of 
which  forces  the  execution  of  some  particular  logical  path 
through  the  program. 

Dynamic  Evaluation  Tools 

In  principle,  anything  that  can  be  learned  about  a 
program  can  be  inferred  from  the  code  and  the  environment  in 
which  it  is  to  be  run.  However,  it  is  usually  more 
economical  to  stop  looking  at  the  program  at  some  point  and 
start  looking  at  its  results.  We  can  imagine  programs  whose 
input  domains  are  small  finite  sets.  Such  programs  can  be 
completely  validated  by  exaustive  testing.  However,  in 
practice  this  class  of  programs  is  so  small  that  exaustive 
testing  is  usually  not  a  useful  option. 

Random  or  Partially  Random  Test  Data.  Tests  with 
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randomly  generated  test  data  are  appealing  because  of  their 
ease  of  implementation.  One  would  like,  for  instance,  to  be 
able  to  specify  a  probability  distribution  on  the  inputs  of 
a  program  and  automatically  generate  a  test  data  set  of  the 
desired  size.  If  the  distribution  of  inputs  in  the  software 
system's  actual  operation  environment  is  known,  one  could 
then  actually  estimate  the  statistical  reliability  of  the 
software.  Here  "reliability"  means  the  probability  that  the 
software  will  function  in  its  operating  environment  for  a 
given  period  of  time  without  failure  [11,131.  However,  in 
practice  the  distribution  of  inputs  is  often  not  known,  so 
random  testing  does  not  then  produce  a  reliability  estimate. 
The  main  problem  with  random  testing  is  that  just  doing  more 
of  it  may  not  necessarily  increase  confidence  in  the  program 
by  much.  A  hundred  random  test  cases  may  test  a  few 
sections  of  the  program  a  hundred  times,  rather  than  testing 
a  hundred  sections  of  the  program.  The  following  small 
experiment  illustrates  this  point. 

The  experiment  was  performed  to  measure  the  effects  of 
program  choice,  test  data  selection  method,  and  data  set 
size  on  the  adequacy  of  test  coverage.  The  coverage  measure 
used  was  the  mutation  score  from  the  first  Fortran  mutation 
system.  The  mutation  score  will  be  discussed  fully  in 
Chapter  II,  but  for  now  it  is  sufficient  to  know  that  the 
scores  range  from  0.0  to  100.0,  with  the  higher  score 
indicating  more  complete  test  coverage.  Two  programs  called 
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J8ST03  and  JBST05,  first  reported  in  [7] ,  were  used  in  the 
experiment.  They  are  both  sorting  programs  so  that  the  same 
test  data  may  be  used,  but  they  are  based  on  different 
algorithms.  The  test  data  selection  methods  are  random 
(from  a  table  of  random  digits),  and  hand  selection.  All  of 
the  hand-selected  data  was  chosen  before  any  testing  was 
performed,  on  the  basis  of  a  general  knowledge  of  sorting. 
The  small  test  seta  were  composed  of  three  vectors,  of 
lengths  1,  5,  and  10.  The  large  test  sets  contained  six 
arrays,  of  lengths  1,  2,  5,  6,  8,  and  10.  Two  replicates  of 
each  combination  were  generated,  and  the  mutation  scores 
were  measured.  The  results  appear  in  Table  1. 


Table  1.  Effects  of  Test  Size,  Selection  Method, 
and  Program  on  Test  Adequacy 

PROGRAM 

Mutation  Scores  Test  Set 


Hand 

Selection 


Random 

Selection 


JBST03 

JBST05 

95.6 

92.5 

small 

96. 3 

92.2 

96.7 

95.2 

large 

96.7 

95.2 

96.3 

94.9 

small 

96.3 

93.8 

96.7 

94.7 

large 

96.7 

94.8 

The  effects  are  small,  since  ell  of  the  test  cases 
score  in  the  90-100  range,  but  there  are  strong 

.(  • 


statistically  identifiable  effects.  Table  2  is  an  analysis 
of  variance  table,  with  effects  aaprogram,  b*data  generation 
method,  and  cutest  case  size.  (See  Appendix  E  for  a  short 
discussion  of  analysis  of  variance.) 


Table  2.  ANOVA  Table  for 
Si ze-Selection-Program  Experiment 


Effect 

Estimate 

SS 

df 

MS 

F 

a 

-2.23 

19.80 

1 

19.80 

176  * 

b 

-0.50 

1.01 

1 

1.01 

8.98 

ab 

-0.32 

0.41 

1  • 

0.41 

3.64 

c 

+1.10 

4.84 

1 

4.84 

43.02  * 

ac 

+  0.55 

1.20 

1 

1.20 

10.67 

be 

+0.71 

2.02 

1 

2.02 

17.96  * 

abc 

+  0.53 

1.11 

1 

1.11 

9.87 

SSE 

0.90 

8 

0.1125 

SST 

31.29 

15 

•  • 

The  effects 

marked 

with  an  asterisk  are 

significant  at 

the  0. 

005  level. 

Thus  we 

see  that 

the  program 

being  tested 

is  a 

major  source  of  variation. 

Despite  the 

fact  that  the 

programs  perform 

the  same  function,  one  is 

more  easliy 

tested 

tnan  the 

other . 

The  size  of  the  test  set  is  also 

important,  with  larger  test  cases 

providing  better  coverage 

on  a 

given  program. 

Neither 

of  these  conclusions  is 

surprising.  Since  the  b 

effect  is 

not  highly 

significant. 

hand  selection  and  random  selection  did  not  produce  very 

different  results 

in  this 

range  of 

sampling. 

However,  the 

significance  of  the  be  interaction  leads  us  .to  believe  that 
as  the  size  of  the  test  data  set  increases,  hand-selected 
test  data  improves  its  performance  faster  than  does  randomly 


selected  test  data.  Thus  random  test  data  may  be  less 
desirable  than  test  data  that  has  been  selected  according  to 
some  plan  that  takes  into  account  properties  oC  programs. 

Symbolic  execution.  One  measure  of  test  data 
effectiveness  is  the  number  of  different  control  paths  that 
the  test  data  will  cause  to  be  executed.  The  ATTEST  system 
described  in  [8,4]  analyzes  the  structure  of  a  program  and 
develops  symbolic  requirements  for  the  traversal  of  given 
paths  in  the  program.  As  the  name  "symbolic  execution" 
suggests,  the  system  steps  through  the  program  accumulating 
symbolic  expressions  rather  than  the  usual  numerical  values. 
A  branch  condition  results  in  a  conditional  expression 
involving  algebraic  formulas.  At  the  end  of  a  path,  then,  a 
compound  logical  expression  involving  algebraic  expressions 
in  the  input  variables  is  obtained.  These  expressions  may 
then  be  solved  automatically  for  input  values  that  will 
drive  execution  down  the  desired  path.  Symbolic  execution 
systems  for  subsets  of  LISP  [4]  and  PL1  [13]  have  been 
reported. 

Program  Instrumentation.  As  was  mentioned  in  the 
preceeding  paragraph,  coverage  of  program  paths  is  a  measure 
of  test  effectiveness.  This  measure  can  be  used  as  a 
driving  criterion  for  test  data  selection,  or  it  can  be 
evaluated  for  test  data  generated  by  arbitrary  processes. 
The  evaluation  of  the  coverage  measure  can  be  implemented  by 
instrumenting  the  program;  that  is,  inserting  instructions 
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that  do  not  affect  the  functional  behavior,  but  which  use 
auxilliary  variables  to  keep  track  of  program  behavior. 
Instrumentation  can  be  used  for  paths  of  arbitrary 
complexity,  but  is  most  often  limited  to  simple  Decision  to 
Decision  Paths  (DDP's)  [27,15]  and  "hidden  paths"  [11] 
within  predicates.  While  many  more  sophisticated  techniques 
are  being  studied,  the  DDP  method  is  widely  available  at  the 
commercial  level  [2,30].  However,  examples  of  simple  errors 
that  could  escape  detection  by  the  DDP  procedure  have  been 
reported  in  [14]. 

Mutation  Analysis.  Mutation  Analysis  produces  a 
measure  of  test  data  effectiveness  that  includes  simple  DDP 
coverage  but  is  much  more  comprehensive.  Test  data  that 
receives  a  high  mutation  analysis  score  must  not  only  force 
the  execution  of  all  program  statements,  but  must  also 
demonstrate  to  a  high  degree  of  confidence  the  correctness 
of  the  operations  along  the  paths.  However  mutation 
analysis  systems  do  not  automatically  generate  test  data. 
But  the  listing  of  live  mutants  is  generally  very  helpful  to 
the  human  tester  in  devising  test  cases.  A  full  discussion 
is  deferred  until  later  sections. 

Other  Approaches  to  Software  Validation 

Formal  Verification.  Formal  verification  has  been 
proposed  in  [20]  as  the  ultimate  program  validation 
technique.  In  this  technique  the  tester  is  required  to 
produce  a  mathematical  proof  that  the  program's  behavior  is 


,f  * 
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consistent  with  its  functional  requirements.  Manual  theorem 
proving  for  programs  is  usally  such  a  large  process  that  the 
technique  depends  on  the  availability  of  automatic  theorem 
provers,  or  at  least  semiautomatic  ones  that  pause 
occasionally  and  ask  for  advice.  Another  requirement  is 
that  the  statements  in  the  programming  language  have  their 
semantics  expressible  in  simple  axioms.  The  key 
reservations  that  many  researchers  have  about  formal 
verification  are 

(1)  Can  formal  verification  be  made  practical  for 
large  software  systems?  This  depends  on 
developing  very  efficient  (in  both  space  and  time) 
theorem  provers.  W.D.  Maurer  recently  reported 
in  [21]  that  verification  of  a  two  page  Gobol 
program  was  obtained  at  the  cost  of  £10,000.  Mr. 
Maurer  was  speaking  in  favor  of  verification. 

(2)  Can  formal  verification  be  made  sufficiently 
reliable?  At  the  present  "proofs"  of  programs  are 
as  subject  to  error  just  as  are  the  programs 
themselves  [10,14].  Reliability  may  be  Improved 
by  improving  the  reliability  of  automatic  tools. 

(3)  Can  production  software  be  formally  specified 
as  completely  as  is  required  for  formal 


verification.  Testing  does  not  usually  require  a 

complete  prior  specification. 

0 

Error  Seeding.  Error  seeding  [13]  treats  the  program 
as  a  statistical  object.  K  known  number  of  errors  are 
deliberately  introduced  into  the  program,  and  testing 
proceeds  until  a  predetermined  number  of  errors  have  been 
discovered.  If  all  errors  are  random,  and  independent,  one 
could  use  the  ratio  of  seeded  to  nonseeded  errors  among 
those  discovered  to  estimate  the  total  number  of  errors 
remaining.  This  is  a  direct  analogy  to  common  wildlife 
population  estimation  techniques.  The  problem  is  that 
experience  shows  that  errors  are  not  random,  objects  [1],  and 
their  clustering  and  dependent  behavior  may  spoil  this 
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CHAPTER  II 


CONCEPTS  OF  MUTATION  ANALYSIS 
Conditional  Correctness 

The  chief  concept  underlying  mutation  analysis  is  that  of 
conditional  correctness. 

Given: 
a  program  P , 

a  class- of  programs  Mj  P«M, 
evidence  B  about  the  program  P. 


1 


Conclude: 

If  a  correct  program  P*  is  in  M  then  either  P 
is  correct  or  E  demonstrates  the  incorrectness  of 
P. 


This  paradigm  is  satisfied ,  for  example,  in  the  case  of  M 
being  the  set  of  programs  for  evaluating  polynomials  of 
degree  <  5.  Then  E  is  the  evaluation  of  P  on  5  distinct 

points.  Given  that  the  desired  program  is  in  fact  in  M,  E 
is  sufficient  to  decide  whether  or  not  P  is  correct.  In 
this  example,  E  is  sufficient  to  distinguish  any  two 
elements  of  M.  In  the  more  general  case,  this  need  not 
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hold.  All  that  is  necessary  is  that  E  distinguish  P  from 
every  element  of  M  that  is  not  equivalent  to  P.  We  say  that 
two  programs  are  equivalent  if  they  have  the  same 
input-output  behavior.  We  say  that  an  element  of  Ml  or  M2 
is  equivalent  (or  nonequivalent)  if  it  is  equivalent  (or, 
respectively,  not  equivalent)  to  P.  This  result  has  been 
extended  to  much  wider  classes  of  programs,  but  those 
extensions  are  still  based  on  polynomial  behavior  [29]. 

Now  consider  a  slightly  more  complicated  situation. 

Given: 

a  program  P, 

two  classes  of  programs  Ml  and  M2;  with  PC  Ml  &  M2, 

evidence  E  about  the  program  P. 


Conclude : 

If 

(a)  there  is  a  correct  program  P'  in  M2  and 

(b)  whenever  E  distinguishes  P  from  all  of 
the  nonequivalent  programs  in  Ml, that  E  also 
distinguishes  P  from  all  of  the  nonequivalent 
programs  in  M2; 

then  either  P  is  correct  or  E  demonstrates  the 
incorrectness  of  P. 

It  is  noted  that  the  second  situation 

;l  - 


is 


mathematically  isomorphic  to  the  first  (Ml  is  redundant.) 
However,  we  will  be  interested  in  the  experimental  situation 
in  which  property  (b)  does  not  actually  hold  completely,  but 
is  rather  a  statistical  description. 

Mutagenic  Operators 

Mutation  analysis  is  an  implementation  of  conditional 
correctness  where  P  is  a  program  written  in  some  programming 
language  and  Ml  is  a  set  of  mutants  of  P.  A  mutant  of  P  is 
a  program  derived  from  P  by  making  a  single,  simple  source 
language  change  in  the  program.  Mutations  are  produced  by 
mutagenic  operators  such  as: 

(in  Cobol)  Reverse  any  two  adjacent  elementary 
items  in  a  record. 

(in  Fortran)  Reverse  the  dimensional  limits  in  a 
two-dimensional  array. 

(in  any  language)  Substitute  for  a  reference  to  a 
variable  a  reference  to  any  other  variable 
appearing  in  the  program. 

The  choice  of  mutagenic  operators  is  influenced  by  three 
concerns : 

(1)  to  Include  most  common  programming  errors 
[11,32] . 

(2)  to  obtain  program  coverage  by  including 
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special  operators  that  indicate  whether  or  not 
statements  have  been  executed,  and  whether  or  not 
those  executions  had  any  effect  on  the  final 
result. 

(3)  to  permit  straightforward  and  efficient 
implementation  in  an  interpretive  or  compiled 
system. 

Evidence  E  results  from  executing  P  and  some  of  its  mutants 
on  a  set  of  test  data.  The  strength  of  the  evidence  is  to 
some  degree  under  the  control  of  the  designer  of  the 
mutation  system.  If  the  set  of  mutagenic  operators 
implemented  in  a  system  allows  test  data  to  pass  mutation 
analysis  (distinguish  P  from  all  of  Ml) ,  and  important 
errors  are  not  detected,  then  the  set  of  operators  can  be 
augmented,  adding  programs  to  Ml  and  strer.g  thing  the 
evidence,  by  forcing  the  user  to  provide  stronger  test  data. 
Similarly,  if  operators  are  found  to  be  of  little  use  in 
testing  (adding  little  strength  to  the  test  evidence) ,  then 
those  operators  may  be  deleted.  Operator  selection  be 
discussed  further  under  the  proposed  experiments. 

The  Competent  Programmer  Assumption  and 
The  Coupling  Effect 

For  any  realistic  choice  of  M2,  either  assumption  (a) 


or  (b) ,  or  both,  will  not  be  fully  satisfied. 

Por  example,  let  M2  be  the  set  of  programs  which  a 
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programmer  might  produce  in  the  course  of  an  effort  to 
produce  a  program  P  which  satisfies  functional  requirements 
f.  Then/  just  assuming  that  the  programmer  could  possibly 
write  a  correct  program,  assumption  (a)  will  be  satisfied. 

v 

But  assumption  (b)  is  probably  not.  For  any  program  P  and 
any  finite  test  set  E  it  is  possible  to  find  some  other 
program  P'  such  that  P  and  P*  agree  on  E  but  nowhere  else. 
If  both  P  and  P1  are  possible  results  of  the  programming 
practice,  then  (b)  will  fail. 

At  the  other  extreme,  let  M2  »  Ml.  Then  assumption 
(b)  is  trivially  satisfied,  but  (a)  is  not,  since  we  know  by 
experience  (Appendix  D)  that  even  the  best  programmers 
produce  programs  that  contain  errors  more  pervasive  than  a 
single,  simple  change.  Another  way  to  view  this  is  that  it 
often  takes  more  than  a  single  change  to  correct  a  "buggy" 
program.  (See  for  example  a  discussion  of  a  program  by  Naur 
in  [14]  .) 

In  mutation  analysis,  we  try  to  balance  the  two 
assumptions  and  choose  an  M2  so  that  neither  is  dramatically 
false.  Even  so,  the  definition  of  M2  is  rather  vague. 
Generally  we  choose  M2  to  be  the  set  of  programs  that  are 
"close"  to  P  in  a  syntactic  sense.  M2  would  contain 
multiple  mutations,  as  well  as  perhaps  simple  missing  path 
errors,  etc.  Assumption  (a)  is  called  the  competent 
programmer  assumption  [11,1]; 

A  competent  programmer,  after  completing  the 
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Iterative  process  and  deeming  that  his  job  of 
designing,  coding,  and  testing  is  complete,  has 
written  a  program  that  is  either  correct  or  is 
almost  correct  in  that  it  differs  from  a  correct 

program  in  "simple"  ways. 


Assumption  (b)  is  called  the  coupling  hypothesis  [11]: 

Test  data  that  is  sensitive  enough  to  detect  all 
simple  errors  is  sensitive  enough  to  detect  most 

likely  complex  errors  as  well. 
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If  the  competent  programmer  assumption  and  the 
coupling  hypothesis  were  completely  valid,  then  mutation 
analysis  would  be  a  perfect  testing  technique.  Since 
elimination  of  all  simple  errors  would  eliminate  all 
possible  errors.  This  work  addresses  the  coupling 
hypothesis,  and  attempts  to  place  statistical  bounds  on  its 
valid ity. 

The  following  is  one  possible  definition  of  a  general 
•coupling  effect". 

Let  P  be  a  program.  Ml  a  set  of  programs,  and  M2 
another  set  of  programs.  We  say  that  M2  is 
coupled  to  Ml  (for  P)  if  whenever  a  set  of  test 
data  T  distinguishes  P  from  all  of  the 
nonequivalent  members  of  Ml,  then  T  also 
distinguishes  P  from  all  of  the  nonequivalent 
members  of  M2. 
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The  existence  of  a  coupling  effect  of  this  type  has  been 

proved  in  16  3  for  decision  table  programs  where  Ml  »  {single 

0 

mutations  of  P}  and  M2  *  (multiple  mutations  of  P>.  In  the 
more  usual  setting  of  Fortran  and  Cobol  programs  with  Ml  * 
{single  mutations}  and  M2  *  {all  likely  errors) ,  then  the 
strong  form  of  the  coupling  effect  does  not  exist,  since 
multiple  mutations  can  escape  detection  by  test  data  that 
are  sufficient  to  detect  first  order  mutations.  This 
problem  will  be  addressed  specifically  in  Chapter  III. 
These  uncoupled  errors,  or  likely  programming  errors  that 
are  not  detected  by  test  data  generated  for  first  order 
mutation  analysis,  will  be  collected  from  the  experiments, 
and  studied  to  see  if  they  suggest  new  mutagenic  operators 
to  be  added  to  our  current  set  in  order  to  strengthen 
mutation  analysis. 

We  can  however  express  the  coupling  effect 
empirically: 

Let  P  be  a  program.  Ml  a  set  of  programs,  and  M2 
another  set  of  programs.  We  say  that  M2  is 
coupled  to  Ml  (for  P)  with  coupling  coefficient 
(1-w)  if  w  is  the  largest  number  such  that: 

for  any  T  distinguishing  P  from  all  nonequivalent 
elements  of  Ml,  the  number  of  elements  of  M2  that 
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are  nonequivalent  and  not  distinguished  by  T  is 
not  greater  than  wlM2l. 


"a 
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Examining  all  possible  test  cases  is  not  in  general  possible 
(else  there  would  be  no  need  for  any  other  testing 
methodologies) ,  so  this  definition  is  operationally 
deficient.  We  can  however  define  another  coefficient  z  to 
be  the  fraction  of  the  nonequivalent  members  of  M2  not 
eliminated  by  some  particular  test  case,  z  is  then  a  random 
variable  over  the  space  of  program/Ml-suf f icient  test-case 
pairs,  whose  upper  bound  is  w.  An  experiment  on  the 
coupling  effect  is  a  measurement  of  the  strength  of  that 
effect  by  measuring  z,  and  hence  estimating  w.  Actually,  z 
itself  would  only  be  estimated  by  sampling.  A  confidence 
interval  (see  Appendix  E)  could  be  determined  for  z.  The 
conclusion  of  such  an  experiment  could  be  of  the  form: 

For  programs  selected  from  population  Q  and  test 
data  generated  by  process  R  (to  a  strength 
sufficient  for  first  order  mutation  analysis)  the 
values  of  z  were  estimated  by  sampling  from  the 
sets  M2  generated  by  process  S  and  were  found  to 
range  from  x  to  y. 

Thus  if  Q  is  similar  to  a  population  of  programs  about 
which  we  want  to  make  quantitative  testing  statements,  and  R 
is  the  testing  procedure  that  we  want  to  quantify,  and  S 
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generates  a  reasonable  distribution  of  cantidate  alternative 
programs,  we  can  use  the  estimated  values  of  z  to  bound  the 
likelihood  that  errors  remain  in  a  program. 

The  validity  of  the  mutation  analysis  technique  thus 
rests  on  the  competent  programmer  assumption  and  the 
coupling  effect.  The  major  effort  in  this  research  is 
toward  finding  the  strength  of  the  coupling  effect,  and  thus 
toward  finding  a  limit  on  the  reliability  af  mutation 
analysis . 

Equivalence  of  Mutants 

Not  all  first  order  mutants  can  be  eliminated,  no 
matter  what  test  data  is  supplied,  since  some  mutant 
programs  will  be  functionally  Identical  to  the  original 
program.  Some  of  these  equivalent  mutants  can  be  detected 
automatically,  with  methods  borrowed  from  code  optimization 
theory  [3,11.  For  example,  changing 

A  :«  0  A  :»  0 
»»> 

B  :■  0  B  :■  A 

is  an  equivalent  mutation  that  can  be  detected  at  compile 
time  and  eliminated  (i.e.  not  generated).  Since 
equivalence  is  formally  undecidable,  we  can  never  hope  to 
detect  all  of  them  this  way.  Mutation  systems  wil*  continue 
to  rely  on  the  human  user  to  judge  the  equivalence  of  some 
mutants.  The  accuracy  of  the  typical  user  in  judging 
equivalence  needs  measurement,  as  does  the  cost  of 
improperly  judging  a  mutant  equivalent  when  in  fact  it 
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represents  a  potential  error. 

Most  equivalent  mutants  encountered  in  testing  are 
very  simple  ones,  like  the  example  above.  Another  major 
source  of  simple  equivalent  mutants  is  the  Inclusion  in  a 
program  of  useless  variable  initializations.  If  a  program 
includes  "A:»0",  and  each  possible  execution  path  has 
another  assignment  to  A  before  A  is  used,  then  the  "0"  in 
"A:=0"  may  be  changed  to  anything  else.  Or  the  A  may  be 
changed  to  any  other  variable  that  does  not  need  a  nonzero 
value  at  that  point.  An  example  of  a  useless  initialization 
in  a  Cobol  program  used  in  this  study  is 

MOVE  SPACES  TO  PRINT-LINE. 

WRITE  PRINT-LINE  FROM  HEADER-LINE  AFTER  PAGE. 

Another  source  of  equivalence  is  assignments  that 
"almost"  don't  matter.  For  example,  if  in  a  Cobol  program 
FLAG  is  used  as  a  boolean  with  'TRUE'  for  true  and  'FALSE' 
for  false,  and  the  only  test  in  the  program  is  IF  FLAG  » 
'TRUE'...  then  an  assignment  FLAG  *  'FALSE'  can  be  changed 
to  FLAG  ■  'HELLO' ,  or  anything  else  other  than  'TRUE' .  A 
statement  such  as  MOVE  ZERO  TO  NUM-1,  where  NUM-1  is  defined 
to  have  no  fractional  part  (e.g.  PIC  ,  can  be  changed 
to  MOVE  0.12  TO  NUM-1,  due  to  the  Cobol  rules  for  numeric 
truncation  in  a  MOVE.  The  detection  of  equivalence  in  other 
cases  may  not  be  so  easy.  Changing  IF  A  ■  11  to  IF  A  IS  NOT 
<  11  may  not  be  judged  equivalent  until  analysis  of  the 
program,  shows  that  A  can  never  be  greater  than  eleven  at 
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THE  COBOL  MUTATION  SYSTEM 

Design  and  History  of  Mutation  Systems 

Automated  systems  to  aid  mutation  analysis  have  been 
developed  [1, 5,11,12,19] .  Such  systems  are  composed  of  the 
following  basic  functions. 

(1)  A  parser  to  reduce  the  source  code  to  an 
internal  form  suitable  for  interpretive  execution 
and  mutation. 

(2)  A  mutation  generator  that  produces  a  list  of 
mutation  descriptions  applicable  to  the  program, 
based  on  its  internal  form. 

(3)  An  Interpreter  that  executes  the  program  or  a 
mutant  program  on  a  test  case  and  records  the 
results  of  execution. 

(4)  A  test  data  handler  and  user  interface  to 
provide  a  convenient  software  test  harness.  This 
allows  the  user  to  submit  test  cases,  examine  the 
results,  and  either  reject  the  test  case  or  accept 
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it  for  further  analysis. 

(5)  A  mutator  that  modifies  the  internal  form  in 
such  a  way  as  to  correspond  to  a  source  language 
error,  and  later  restores  the  program  to  its 
internal  form. 

(6)  A  report  generator  that  summarizes  information 
to  the  users  terminal  and  to  a  permanent  file  in 
which  is  stored  the  status  of  the  mutation 
analysis,  the  mutants  remaining,  and  the  test 
cases . 

The  first  automated  mutation  system  was  FMS.l  (for 
Fortran  Mutation  System  —  version  1)  developed  at  Yale 
University  [11].  FMS.l  was  developed  on  a  PDP  10  and  was 
later  transported  to  a  PRIME  400  at  Georgia  Tech,  a  DEC  20 
at  Yale  University,  and  a  VAX  11  at  the  University  of 
California,  Berkeley.  FMS.l  treats  only  a  subset  of 
Fortran:  a  single  subroutine  with  integer  arithmetic  and 
without  I/O.  Success  with  this  pilot  system  was  sufficient 
to  motivate  the  construction  of  more  elaborate  systems. 

FMS.2  was  also  developed  at  Yale  and  transported  to 
Georgia  Tech.  It  accepts  multiple  subprograms  in  full  AMSI 
Fortran  (minus  I/O)  [19,1].  FMS.l  is  less  of  a 
user-oriented  system  than  FMS.l,  and  was  designed  primarily 


to  allow  the  flexible  design  of  mutation  experiments. 

CMS.l,  a  mutation  system  for  Cobol,  was  designed  at 
Georgia  Tech  by  the  author  and  implemented  on  the  Georgia 
Tech  PRIME  400.  The  design  owes  much  to  the  earlier  FMS.l, 
as  well  as  to  discussions  with  its  designers.  For  a  full 
discussion  of  this  system,  see  appendices  A,B,  and  C. 

A  Case  Study 

During  the  development  of  CMS.l  the  author  had 
difficulty  debugging  a  subroutine  called  NXTLIV.  Since 
CMS.l  is  written  in  Fortran,  it  was  decided  to  test  the 
subroutine  under  FMS.l.  (FMS.2  was  not  then  available  at 
Georgia  Tech.)  It  was  necessary  to  modify  the  subroutine 
somewhat  in  order  to  conform  to  the  FMS.l  Fortran  subset, 
but  it  was  felt  that  the  error(s)  probably  did  not  lie  in 
the  code  that  required  modification.  A  condensed  script  of 
the  testing  session  appears  as  Appendix  D.  One  error  was 
found  quickly.  The  ease  of  finding  the  error  is  probably 
due  less  to  mutation  itself  than  to  the  convenient 
subroutine  test  harness  provided  by  FMS.l.  A  second  error 
was  found  later,  however,  as  a  direct  result  of  trying  to 
eliminate  one  of  the  last  remaining  mutants.  An  interesting 
note  is  that  the  mutant  being  considered  was  not  the 
correction  of  the  error,  but  another  mutant  yet  to  be 
considered  was.  This  is  an  example  of  the  coupling  effect. 
Detection  of  one  potential  error  automatically  detected 
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Programs  Used  In  This  Study 

Most  o£  the  experiments  reported  here  use  data 
generated  from  six  Cobol  programs  obtained  from  several 
sources.  Each  of  the  programs  was  modified  slightly  to  fit 
in  the  CMS.l  Cobol  subset.  One  typical  modification  was  the 
replacement  of  a  serial  disjunction  of  the  form 

IP  A  »  'A'  OR  'C'  OR  ‘Q* 
by  the  equivalent  form 

IF  A  »  'A'  OR  A  »  *C»  OR  A  »  ’Q' 

Another  is  the  replacement  of  a  condition  name  by  its 
defining  condition.  In  some  programs  record  sizes  were 
reduced  without  affecting  program  logic.  Listings  of  the 
programs  as  tested  may  be  found  in  Appendix  F. 

Program  1  is  from  the  Army  SIDPERS  personnel  system, 
and  contains  145  lines  of  code.  In  its  original  form  there 
were  otptional  sections  for  different  input  forms  (disk  and 
tape)  and  different  output  dispositions  (disk  and  printer). 
These  options  were  deleted  to  conform  to  the  CMS.l 
sequential  input  -  sequential  output  restriction.  The 
deleted  code  is  essentially  a  copy  of  retained  code  with 
different  options  on  the  READ  and  WRITE  statements.  No 
errors  were  found  in  this  program  during  the  experiments. 
The  progam  has  two  input  files,  both  containing  a  key  and 
information  field.  The  files  are  presumed  sorted  on  the  key 
fields,  and  represent  old  and  new  master  files.  The  program 
produces  a  log  of  the  differences  between  its  two  input 
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files.  Program  1  is  used  to  illustrate  the  use  of  CMS.l  in 
Appendix  C. 

Program  2  contains  163  lines  of  code  and  was  written 
by  a  student  at  Georgia  Tech  as  an  exercise.  The  program 
accepts  account  transactions  and  performs  one  of  several 
simple  computations  based  on  a  class  code  in  the  input 
record.  Data  validation  is  performed,  and  the  output 
consists  of  one  record  for  each  input  transaction,  plus 
summary  statistics  by  class. 

Program  3  is  adapted  from  Learning  to  Program  in 
Structured  Cobol  [33].  Input  transactions  are  in  the  form 
of  pairs  of  records.  For  each  pair  the  first  record  is  a 
name-address-phone-account-number  record,  and  the  second 
contains  credit  information.  From  that  credit  information 
discretionary  income  is  computed  by  a  standard  formula.  The 
purpose  of  the  program  a  readable  listing  of  the  input  file 
with  name  and  address  in  one  column  and  decoded  credit 
information  in  another.  One  small  error  was  found;  there 
was  code  to  handle  the  situation  of  an  end-of-file  after  the 
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first  card  of  a  pair,  but  this  code  did  not  bring  execution 
to  a  graceful  end.  Instead,  the  program  terminated 
abnormally  several  statements  later  when  another  READ  was 
attempted.  There  were  also  several  useless  initializations. 
Such  useless  statements  are  a  nuisance  in  mutation  analysis 
since  they  can  be  changed  to  -  any  other  useless  statement 
without  affecting  the  input-output  behavior  of  the  program. 
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Program  4  is  adapted  from  ANS  Cobol:  A  Pragmatic 
Approach  [25]  where  it  is  called  SRMFREP.  The  input  records 
are  codings  of  student  academic  data,  including  name, 
address,  major,  status,  and  a  number  of  '  course  items 
consisting  of  the  department,  credit,  and  grade  for  each 
course  taken.  The  program  computes  the  students'  grade 
point  averages  and  produces  a  listing  with  name,  address, 
and  other  information  in  one  column,  and  three  columns  of 
course  reports.  The  original  program  was  written  to  accept 
very  long  input  records  {>1000  characters).  Since  CMS.l 
allows  a  maximum  of  150  characters  per  record,  some 
abbreviation  was  necessary.  The  identifying  fields  were 
shortened,  and  the  maximum  number  of  course  reports  reduced 
to  11.  One  error  was  found;  code  to  handle  invalid  input 
records  could  sometimes  refer  to  undefined  data  fields. 

Program  5  was  also  written  by  a  student  at  Georgia 
Tech.  Input  transactions  contain  identifying  codes  for  a 
store,  a  department,  and  a  salesman.  The  salesman's  name, 
year-to-date  sales,  current  sales,  commission  rate,  and 
months  employed  are  also  included.  In  the  computation, 
commision  bonuses  are  paid,  depending  on  the  department  and 
the  average  sales  volume.  Some  data  validation  is 
performed,  and  error  report  records  are  interspersed  with 
valid  transaction  report  records.  One  functional  error  was 
discovered  during  testing.  If  a  page-full  condition  is 
raised  by  the  printing  of  an  error  report,  then  no  heading 
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would  be  generated  for  the  following  page.  Several  data 
flow  anomolies,  such  as  useless  initializations,  were 
detected . 

Program  6  is  also  taken  from  Learning  to  Program  in 
Structured  Cobol  [33],  and  was  written  as  an  extension  to 
Program  3.  In  addition  to  computing  discretionary  income,  a 
credit  limit  is  computed  based  on  discretionary  income, 
marital  status,  home  ownership,  and  job  tenure.  Rather  than 
just  creating  a  listing  from  its  input,  the  program  uses  the 
input  as  transactions  against  a  master  file.  The  input  and 
master  files  are  presumed  to  be  sorted  by  account  number, 
and  a  new  master  is  produced.  A  separate  log  of 
transactions  and  errors  is  also  generated.  The  transaction 
types  are  add,  delete,  and  change  master  records.  This 
program  was  apparently  not  tested  before  publication,  since 
it  did  not  function  properly  on  any  input.  Faulty  program 
logic  caused  the  last  transaction  card-pair  to  be  ignored. 
An  empty  transaction  file  caused  abnormal  termination.  The 
input  is  validated  in  one  section  of  the  program,  but  not  in 
another  similar  section.  If  the  first  card  pair  is  an 
invalid  transaction,  the  error  message  is  placed  in  the  log 
file  before  the  log  file  header.  Many  extra  initializations 
and  data  field  definitions  are  present,  due  largely  to  the 
free  use  of  the  COPY  verb.  The  program,  after  correction, 
contains  619  lines. 

Test  Data  Generation 
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Test  data  for  use  in  the  experiments  was  generated  in 
the  way  in  which  we  would  expect  such  data  to  be  generated 
in  production  use  of  a  mutation  system.  A  tester  (in  this 
case  the  author)  first  manually  generated  tests  to  cover  the 
major  points  of  the  specification.  For  example,  if  a 
program  is  supposed  to  produce  one  type  of  record  for  a  zero 
input  field  and  another  type  if  the  field  is  nonzero,  the 
test  data  would  include  both.  Actually  this  initial  test 
data  does  not  even  have  to  be  very  good,  because  of  the 
feedback  supplied  by  the  mutation  system.  The  tester  enbles 
a  subset  of  the  mutants,  and  starts  a  mutation  run.  The 
mutants  alive  (i.e.  not  eliminated 

not  differentiated  fron  the  original  program)  at  the 
end  of  the  run  suggest  new  test  data  that  the  tester  must 
generate.  This  cycle  continues  until  all  nonequivalent 
mutants  have  been  eliminated.  Then  a  larger  subset  of 
mutants  is  enabled.  Testing  continues  as  before  until  all 
nonequivalent  mutants  are  eliminated.  The  subsets  used  in 
this  study  are 

1)  The  TRAP  mutants.  Elimination  of  these  requires 
that  all  statements  In  the  program  be  executed. 

2)  A  random  10%  of  all  substitution  mutants,  and  all  of 
the  other  types.  This  seems  to  yield  strong  test  data 
with  reduced  computational  effort  [1]. 

3)  All  mutants  that  can  be  generated  by  the  system. 

(See  Appendix  A  for  a  list  of  the  mutagenic  operators 

;f  ■ 


supported  by  CMS.l.) 

Program  Statistics 

The  results  of  mutation  analysis  on  the  six  programs 
is  summarize  in  Table  3,  which  shows  for  each  o£  the  six 
programs  the  number  of  program  lines,  the  number  of  mutants 
when  the  substitution  mutants  are  generated  with  probability 
0.1,  the  number  of  those  mutants  equivalent  to  the  original 
program,  the  total  number  of  mutants  that  can  be  generated, 
and  the  number  of  those  that  are  equivalent. 


Table  3.  Mutation  Statistics  on  the  Six  Programs 


Program 

number 

lines 

1  number 

1  mutants 

1  at  10%  * 

number  1 
equiv.  I 
at  10%  1 

number 
mutants 
at  100% 

n  umbe  r 
equiv. 
at  100% 

1 

146 

i  339 

17  | 

1098 

21 

2 

1S3 

1  603 

36  1 

2814 

47 

3 

238 

1  1125 

61  1 

5340 

106 

4 

321 

I  1609 

58  1 

7334 

95 

5 

455 

1  1527 

92  1 

7957 

228 

6 

619 

1  4011 

128  1 

28275 

428 

*  10%  of  substitution  mutants,  100%  of  other  types. 


Empirical  Complexity  of  Mutation  Analysis 

With  the  operators  now  in  use  in  the  various  mutation 
systems,  it  has  been  seen  that  the  number  of  mutants  of  a 
given  program  is  approximately  proportional  to  the  square  of 
the  length  of  the  program  [1J.  For  Cobol  programs  perhaps  a 


better  estimator  of  the  number  of  mutants  is  the  product  of 
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the  data  division  length  and  the  procedure  division  length. 
Indeed  we  can  almost  predict  such  an  empirical  law  from 
first  principles.  Some  of  the  mutant  types  are  inherently 
bounded  by  linear  growth  in  the  program  size.  Examples 
would  be  arithmetic  operator  substitutions,  in  which  there 
are  a  fixed  number  of  substitutions  to  be  made  for  each 
occurrence  of  an  operator  in  the  program.  The  number  of 
such  source  operations  is  no  more  than  the  length  in 
characters  of  the  source  program.  The  dominant  mutant 
types,  for  large  programs,  are  the  operand  substitution 
types  [1].  The  number  of  those  is  bounded  by  the  number  of 
data  references  in  the  program  times  the  number  of  distinct 
data  items  to  be  referenced.  Both  of  those  are  bounded  by 
the  length  of  the  program  (or  for  Cobol,  by  the  length  of 
the  procedure  division  and  the  data  division,  respectively.) 
Figure  1  plots  the  logarithm  of  the  program  size  in  lines 
against  the  logarithm  of  the  number  of  mutants  from  Table  3. 
Since  the  points  seem  to  lie  about  a  straight  line  with 
slope  1/2,  we  see  that  the  number  of  mutants  is  quadratic  in 
program  size.  The  graph  also  shows  the  number  of  equivalent 
mutants  for  the  programs.  We  see  that  the  number  of 
equivalent  mutants  is  also  quadratic  in  program  size.  This 
could  be  troublesome  for  larger  programs  unless  most 
equivalent  mutants  can  be  detected  automatically. 


t  ■ 


Figure  1.  Log-Log  Graph  of  Program  Size  vs.  Number 
of  Mutants  and  Number  Equivalent 
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CHAPTER  IV 

EXPERIMENTS  ON  THE  COUPLING  HYPOTHESIS 

Empirical  evidence  has  been  found  [1]  for  the  coupling 
effect  for  Fortran  programs,  but  this  evidence  is  weak  in 
that  only  a  very  few  programs  have  been  studied  in  a  limited 
way.  This  research  will  extend  these  results  by  more 
extensive  studies  in  an  attempt  to  place  bounds  on  the 
statistical  validity  of  the  coupling  effect. 

A  series  of  experiments  has  been  devised  to  test  the 
hypothesis  that  testing  a  program  to  a  degree  sufficient  to 
eliminate  first  order  mutations  is  necessarily  also 
sufficient  to  eliminate  most  likely  complex  mutations  as 
well.  The  experiments  all  have  the  same  basic  format: 

Step  1:  for  a  given  program,  generate  test  data  using  a 
mutation  analysis  system,  sufficient  for  first  order 
mutation. 

Step  2:  Randomly  generate  a  large  number  of  more  complex 
mutants,  execute  the  resulting  programs  on  the  test  data 
from  step  1,  and  list  mutants  not  eliminated. 

Step  3:  Manually  examine  the  list  to  remove  equivalent 
mutants . 

In  step  2  in  all  cases.,  we  use  uniform  sampling  with 
replacement  from  a  given  space  of  complex  mutants.  Thus  the 

,  (  ■ 
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parameters  of  each  experiment  are  the  program  being  tested, 
the  tester,  the  type  of  complex  mutants  considered,  and  the 
sample  size.  These  experiments  were  performed  using  a 
single  tester  (the  author) ,  and  a  single  set  of  test  data 


for  each  program.  The  repetition  of  these  experiments  by 
other  investigators  would  enable  us  to  estimate  the 
variation  in  the  coupling  effect  due  to  test  data 
generation. 

Random  Pairs  of  First  Order  Mutants 

One  place  to  start  looking  at  the  coupling  effect  is 
with  “complex  errors"  defined  as  pairs  of  simple  mutants. 
It  is  not  reasonable  to  look  at  all  possible  pairs  of 
mutants  because  of  their  number.  A  small  sample  program 
might  have  on  the  order  of  ten  thousand  mutants,  giving  a 
hundred  million  mutant  pairs.  (Actually  the  number  would  be 
somewhat  less,  since  not  all  pairs  are  possible,  but  the 
order  of  magnitude  is  correct.)  It  is  quite  feasible  to  run 
that  many  mutants,  but  the  number  of  mutants  that  must  then 
be  examined  by  hand  for  equivalence  is  unmanagable.  We  can 
obtain  sufficient  information  by  selecting  a  reasonable 
number  (in  this  case  50,000)  mutant  pairs  from  one  program, 
and  then  selecting  more  from  a  different  program,  and  so 
forth.  Sampling  programs  as  well  as  mutants  will  make  any 
conclusions  more  general.  When  the  coupling  effect  is  total 
(w*1.0),  test  data  developed  to  eliminate  all  first  order 


nonequivalent  mutants  eliminates 


higher-order 


all 
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nonequivalent  mutants  as  well.  Since  the  coupling  effect  is 
not  expected  to  be  total  in  practice,  what  we  need  is  a 
confidence  interval  on  the  fraction  of  second  order  mutants 
that  are  not  equivalent  and  are  not  eliminated  by  data 
chosen  to  eliminate  first  order  mutants.  If  we  find  any 
such  "bad"  second  order  mutants,  we  can  obtain  a  two-sided 
confidence  interval  on  that  fraction  (see  Appendix  E) .  If 
we  find  none,  then  we  can  still  obtain  a  one-sided  (upper 
bound)  confidence  interval.  This  will  give  us  an  estimate 
of  the  probability  that  an  error  of  the  type  {second  order 
mutation)  would  escape  detection  in  mutation  analysis.  For 
this  experiment  pairs  of  mutants  were  selected  uniformly 
from  the  list  of  first  order  mutants,  by  a  pseudo-random 
number  gererator.  There  were  some  technical  difficulties. 
A  mutant  is  a  mutant  of  a  particular  program,  and  may  not 
have  meaning  for  another.  In  particular,  if  S  and  T  are 
mutations  to  a  program  P,  producing  programs  S  (P)  and  T(P), 
then  T(S (P) )  may  not  necessarily  be  a  legitimate  mutant  of 
S  (P) .  For  example,  if  S  is  "Delete  statement  27"  and  T  is 
"In  statement  27  replace  I  by  J",  then  T  cannot  follow  S. 
So  in  the  selection  procedure  such  things  had  to  be  avoided. 
The  method  was  to  select  a  pair  of  mutations,  check  their 
validity  as  a  pair,  and  make  the  mutation  if  valid.  Invalid 
pairs  were  discarded.  The  process  continued  until  the 


required  number  of  valid  pairs  had  been  selected.  The 
results  are  summarized  in  Table  4, 


Table  4.  50,000  Random  Pairs  of  Mutants 
for  Each  Program 


Program 


Pairs  Survive 
1st  Order 
Test  Data 


Not  Equiv, 


95%  Confidence 
Interval  on  I 
(z  *  100,000)**! 


7.4 

7.4 

23.3 

14.4 

7.4 

7.4 


**  z  is  the  probability  that  a  randomly  selected  pair  of 
simple  mutants  would  generate  an  uncoupled  complex  error 
for  this  test  data. 


The  numbers  are  very  favorable  for  mutation  analysis. 
Test  data  generated  to  be  sufficient  for  first  order  mutants 
proved  to  be  sufficient  for  at  least  99.975%  of  all  second 
order  mutants  in  all  cases  considered,  and  99.992%  in  most 
cases.  These  results  can  be  stated  in  several  ways.  In  the 
terminology  of  Chapter  II,  the  coefficient  of  coupling  of 
the  set  {first  order  mutants)  to  the  set  (second  order 
mutants)  for  a  given  program  is  very  close  to  unity. 
Significantly,  program  size  does  not  seem  to  be  an  important 
factor  in  the  coefficient.  In  terms  of  implications  for  the 
design  of  mutation  analysis  systems,  the  addition  of  second 
order  mutations  gives  almost  no  power  not  already  present  in 
first  order  mutations,  and  certainly  not  enough  to  justify 


their  cost. 
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However,  uncoupled  mutants  were  found  in  the 
experiment,  and  they  may  lead  to  insights  into  how  mutation 
analysis  may  be  strengthened  in  other  dimensions,  such  as 
the  choice  of  first  order  mutagenic  operators.  All  of  the 
uncoupled  mutants  found  were  pairs  of  alterations  to  a 
predicate;  either  changing  a  comparison  operator  and  one  of 
its  operands  (Type  A) ,  or  changing  both  operands  of  a 
comparison  operator  (Type  B)  .  There  were  four  type  A 
mutants,  one  of  which  is 

IF ( MARITAL-STATUS-WS  *  'S') 

*»>  • 

IF(NAME-L1  <  'S') 
and  three  type  B  mutants,  like 

IF(SOC-SEC-IN  NOT  »  'qqqqqqqqq') 

»> 

IF( AODR-IN— 2  NOT  »  SOC-SEOF1) 

If  we  treat  the  uncoupled  mutation  as  a  potential  error  (or 
correction)  to  the  program,  then  they  represent  a  form  of 
coincidental  correctness:  taking  the  right  path  for  .the 

wrong  reason. 

Correlated  Pairs  of  First  Order  Mutants 

It  has  been  suggested  [I]  that  completely  random  and 
independent  sampling  is  not  really  a  fair  test  of  the 
coupling  effect.  Most  single  mutants  are  unstable  and  are 
eliminated  rather  easily,  and  so  random  pairs  will  be  even 
more  unstable.  Perhaps  we  should  look  not  at  independent 
pairs,  but  rather  at  pairs  of  errors  that  have  a  chance  of 
producing  subtle  errors.  Those  would  be  pairs  of  mutations 
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that  "almost  cancel".  Me  can  develop  the  capability  of 
automatically  generating  "correlated"  mutant  pairs.  A 
proposed  criterion  for  such  pairs  is  that  they  either  refer 
to  the  same  variable  or  to  the  same  statement.  A  weaker 
restriction  would  be  that  they  refer  to  statements  that 
reference  the  same  variable.  Note  that  all  of  the  uncoupled 
errors  from  the  previous  experiment  fit  this  criterion.  The 
•  procedure  for  pair  selection  is  to  randomly  select  a  pair  of 
substitution  mutants,  and  check  to  see  if  they  reference 
statements  which  reference  the  same  data  item  (either  a 
variable  or  a  constant) .  Pairs  that  alter  the  same 
reference  in  the  same  statement  are  not  considered,  since 
they  are  in  effect  first  order  mutations.  The  procedure  is 
repeated  until  10,000  correlated  pairs  are  generated  and 
tested  for  each  program.  The  results  are  presented  in  Table 
5,  where  for  each  program,  10,000  correlated  mutant  pairs 


were  created 


Table  5.  10,000  Correlated  Pairs  of  Mutants 

for  Bach  Program 


1 

Program  I 

Pairs  Survive 

Not  Equiv. 

1  95%  Confidence 

1 

1 

! 

1st  Order 

1  Interval  on 

1 

I 

1 

Test  Data 

1  (2  *  100,000)** 

1 

1 

1  | 

0 

0 

i  0.0  —  35.9 

1 

1 

2  1 

3 

1 

1  0.3  —  55.7 

1 

1 

3  1 

60 

19 

1  114.4  —  295.6 

1 

1 

4  1 

3 

3 

1  6.1  —  87.6 

1 

1 

5  1 

1 

0 

!  0.0  —  35.9 

1 

1 

5  1 

1 

0 

I  0.0  —  36.9 

1 

**  2  is  again  the  probability  that  a  randomly  selected 
complex  mutant  of  the  current  type  would  represent  an 
uncoupled  error  for  the  given  test  data. 


Eighteen  of  the  uncoupled  mutants  are  of  Type  A,  defined  in 
the  previous  section.  Four  are  of  Type  B.  The  other 
uncoupled  mutant  is  also  a  pair  of  mutations  to  a 
conditional  expression,  but  the  two  mutations  do  not  affect 
the  same  comparison.  The  complex  mutation  is 
IF(ACCOUNT-NUM  IS  NUMERIC  AND  BILLED-AMOUNT  IS  NUMERIC 
AND. .. 

is  changed  to: 

IF(ACCOUNT-NUM  IS  NOT  NUMERIC  AND  BILLED-AMOUNT  IS  NUMERIC 
OR  ... 

The  experience  of  performing  this  experiment  showed 
that,  while  the  number  of  correlated  mutant  pairs  increase 
as  program  size  grows,  the  fraction  of  all  mutant  pairs  that 
are  correlated  diminishes.  Therefore,  the  experiment  was 
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extremely  time-consuming  (in  terms  of  computer  time)  for 
large  programs.  This  effect  would  be  expected  to  intensify 
for  higher  order  mutation,  or  larger  programs.  Thus  because 
of  practical  constraints,  the  correlation  of  mutants  cannot 
be  studied  further  using  the  method  of  this  experiment. 
Higher  Order  Mutants 

It  is  also  possible  to  look  at  triples  of  mutants,  or 
even  mutants  of  higher  order.  We  do  not  need  to  carry  this 
too  far.  The  more  errors  introduced  into  a  program  (or  from 
another  point  of  view,  the  more  changes  necessary  to  make  a 
faulty  program,  correct)  the  more  we  violate  the  competent 
programmer  assumption.  But  we  do  need  some  data  on  multiple 
mutations,  just  to  assure  ourselves  that  nothing  drastic 
happens  as  the  order  of  mutation  increases.  For  this 
experiment  20,000  complex  substitution  mutants  of  each  of 
the  orders  2,  3,  4,  and  5  were  generated  for  each  of  the  six 
programs.  We  restrict  ourselves  to  substitutions  to  avoid 
the  technical  difficulties  discussed  in  the  random  pair 
experiment.  As  was  stated  in  the  preceeding  section,  it  is 
not  feasible  to  look  at  high  order  correlated  mutants.  The 
tuples  were  checked  to  make  sure  that  all  mutations  were 
applied  to  different  data  references.  The  following  table 
shows  the  number  of  mutants  that  passed  the  first  order  test 
data  for  each  program,  and  the  number  that  were  not 


equivalent  (uncoupled  mutants) . 
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Table  6.  20,000  Mutants  of  Order  2,3,4,  and  5 

for  Each  Program 


Program 

»1  *2  13  14  15  16 


2nd  Order 
Mutants 


1  Number  ! 

1 

1 

1 

l 

1 

-  1 

1  tha  t  1 

1 

1 

2 

1 

5 

! 

0 

1 

q 

1 

5 

1  Pass  Test  } 

1 

1 

1 

1 

1 

1  Uncoupled  I 

1 

1 

1 

1 

1 

1  Errors  1 

0 

1 

0 

1 

1 

1 

0 

1 

0 

1 

0 

1  (Nonequiv .) 1 

1 

1 

1 

1 

1 

1  Number  t 

1 

1 

1 

1 

1 

1  that  1 

0 

1 

•0 

1 

0 

1 

0 

1 

0 

1 

0 

1  Pass  Test  ! 

1 

1 

1 

1 

1 

1  Uncoupled  1 

1 

1 

1 

1 

1 

I  Errors  ! 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1  (Nonequiv.)  1 

1 

1 

1 

I 

I 

1  Number  1 

1 

1 

1 

1 

1  that  1 

0 

1 

0 

1 

0 

! 

0 

1 

0 

1 

0 

1  Pass  Test  ! 

1 

1 

1 

1 

1 

1  Uncoupled  I 

1 

I 

1 

1 

1 

1  Errors  1 

0 

1 

0 

1 

0 

l 

0 

1 

0 

1 

0 

1  (Nonequiv.)  1 

1 

1 

1 

1 

1 

1  Number  1 

1 

1 

1 

1 

1 

1  that  t 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1  Pass  Test  1 

1 

1 

1 

1 

1 

I  1 

1  Uncoupled  I 

1 

1 

1 

1 

1 

1  Errors  1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

l 

0 

1 (Nonequiv.) 1 

1 

1 

1 

1 

1 

3rd  Order 
Mutants 


4th  Order 
Mutants 


5th  Order 
Mutants 


There  are  no  surprises  In  this  data.  Higher  order 
mutants  are  more  easily  eliminated.  The  one  uncoupled  error 
Is  of  Type  A.  The  implication  of  this  data  Is  that,  at 
least  for  the  class  of  potential  errors  that  are 
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representable  as  combinations  of  simple  mutations#  our 
experiments  on  mutant  pairs  will  serve  to  provide  upper 
bound  information  on  the  incidence  of  uncoupled  errors# 
since  higher  order  mutations  are  extremely  unlikely  to  be 
uncoupled. 

One  other  statistic  was  generated  during  this  case 
study.  For  each  program  and  each  order  of  mutation,  the 
average  number  of  statements  executed  per  mutant  before  the 
termination  of  execution  (by  normal  end  or  error)  was 
calculated . 

Table  7.  Average  Statements  Executed  Before  Failure 
on  Programs  with  Multiple  Order  Mutations 


1 

Program  1 

2nd  Order 

1 

3rd  Order 

1 

4th  Order 

1  5th  Order 

1 

1 

1  1 

30 

1 

24 

1 

21 

1  19 

1 

1 

2  I 

47 

1 

27 

1 

19 

1  15 

I 

1 

3  I 

50 

1 

38 

1 

31, 

1  27 

1 

1 

4  1 

124 

1 

35 

1 

a  7 

1  59 

1 

I 

5  1 

52 

1 

35 

l 

27 

(  22 

1 

I 

6  1 

132 

1 

98 

1 

74 

1  60 

1 

Many  software  reliability  estimates  are  based  on  the 

assumption  that  the  probability  of  failure  in  a  given  time 

interval  of  a  program  is  proportional  to  the  number  of 

errors  In  the  program  1131.  If  that  were  true#  then  the 

expected  time  to  failure  of  the  program  would  be  inversely 

proportional  to  the  number  of  errors  present.  For  if  T  is 

the  time  to  failure  (say  in  statements  executed)  #  and  cn  is 

the  probability  of  failure  during  the  execution  of  any  given 
statement.  The  the  expected  time  to  failure  is  given  by 

f  • 


4 


Number  of  Errors 


Figure  2 
vs. 


.  Inverse  of  Time  to  Failure 
Number  of  Seeded  Errors 


(i-1) 


E(T)  ?  (1-cn)  (cn)(i) 

V  1*1 


which  reduces  to 

1 

E (T)  -  - 

cn 


Table  7  then  represents  a  simulation  study  of  this 
assumption.  As  the  graph  in  Figure  2  shows,  the  assumption 
is  supported  quite  well.  Not  only  is  there  apparently  a 
strong  linear  relationship  between  1/Avg (T)  and  n  for  each 
of  the  programs,  but  also  for  all  but  one  of  the  programs 
the  line  segments  can  be  extrapolated  backwards  to  show 
intercepts  near  2ero.  That  one  program  is  the  smallest  and, 
presumably,  the  worst  simulation  of  a  large  software  system. 
This  data  cannot  be  interpreted  as  complete  proof  of  the 
assumption  on  the  probability  of  program  fialure,  however, 
since  the  assumption  is  based  on  typical  "live"  input  data. 
The  test  cases  that  generated  the  data  were  intentionally 
chosen  to  be  nontypical,  in  that  the  test  cases  were 
required  to  execute  exception-handling  code  that  would 
rarely  be  executed  in  practice. 


Coupling  and  Complexity 


It  is  possible  that  some  attributes  of  programs 


measurable  by  objective  means  would  have  some  influence  on 


the  strength  of  coupling.  One  such  attribute  to  be  studied 
is  the  structural  complexity  of  programs  (measured  for 

(  • 
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example  by  the  number  of  branches) .  One  problem  with 

another  testing  strategy,  DO  path  coverage,  is  that  it  may 

/ 

take  test  data  forcing  the  program  down  a  particular  complex 
path  in  the  program  to  force  the  discovery  of  an  error.  For 
example  consider  the  following  small  program  to  sort  the 
tuple  ( A, B ,C)  . 

LI:  if  A<B  then  goto  L2; 

T:«A;A: »B;B: ®Cj 

L2:  if  B<C  then  goto  L3; 

T:®A;A:aC ;C:“T; 

L3:  if  B<C  then  goto  L4; 

Tj^BjB^C.'Cj^T; 

L4:  stop 

The  program  is  incorrect.  The  condition  at  L2  should  be 
A<C .  The  input  tuples  (1,2,3)  and  (3,2,1)  for  A,B,and  C 
both  give  correct  results,  and  force  the  execution  of  all 
DDP's.  (1,2,3)  takes  the  TRUE  branches  at  LI,  L2,  and  L3, 
while  (3,2,1)  takes  the  FALSE  branches.  It  is  when  trying 
to  develop  a  test  case  that  will  cause  the  execution  of  the 
complex  path  having  different  results  at  the  last  two  tests 
(TRUE  at  L2  and  FALSE  at  Ll,  or  vice  versa) ,  that  the  error 
must  be  discovered.  So  simply  covering  all  simple  path 
segments  may  not  be  sufficient.  It  is  possible  that 
mutation  analysis  has  this  same  weakness,  since  mutations 
are  of  a  highly  localized  nature.  Any  weakness  would  be  to 
a  lesser  degree,  however,  since  mutation  analysis  includes 
DD  path  coverage  as  a  subcase.  To  test  the  relationship  of 
complexity  to  coupling,  we  hypothesize  that  the  more 
branches  a  program  has,  the  harder  it  is  to  test  adequately 
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by  nutation  analysis.  If  this  is  true,  the  more 
structurally  complex  the  program,  the  higher  the  proportion 
of  uncoupled  potential  errors  we  would  expect.  An 
experiment  to  test  this  hypothesis  would  match  programs  for 
length  and  number  of  mutants,  but  of  differing  branch«count , 
and  would  measure  the  coupling  coefficient  defined  in 
Chapter  II.  If  the  confidence  intervals  on  the  estimates  of 
the  coefficients  overlap,  then  we  detect  no  relationship. 
If  they  do  not,  then  we  have  a  statistical  relationship.  If 
the  relationship  is  found  to  hold,  it  would  be  an  argument 
for  simplicity  in  program  structure  for  programs  to  be 
tested  by  mutation  analysis.  Currently  mutation  analysis 
does  not  suggest  that  simplicity  is  a  virtue.  For  this 
experiment,  "live"  data  could  not  be  used.  Instead,  a 
sequence  of  small  programs  was  written,  all  using  the  same 
data  items  and  data  references,  but  with  an  increasing 
number  of  branches.  The  Experiment  used  50,000  pairs  of 
mutants  for  each  program.  Table  3  shows  the  number  of 
branches,  test  case  records,  mutants,  pairs  passing  the  test 
data,  and  uncoupled  mutants  (mutants  that  pass  but  are  not 
equivalent)  for  each  program. 
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Table  8.  Comlexity  and  Coupling 


1 

Program  1 

Number 

1  Number 

1  Number 

Number 

1 

Number  1 

1 

t 

of 

1  of 

I  of 

that 

1 

Uncoup- 1 

I 

1 

Branches 

1  Records 

I  Mutants 

Pass 

1 

led  1 

1 

C-l  | 

0 

1  1 

i  474 

329 

1 

0  1 

1 

02  ! 

1 

)  3 

1  430 

153 

1 

1  1 

I 

03  | 

3 

1  7 

1  492 

34 

1 

1  1 

1 

04  1 

5 

i  12 

1  504 

SO 

1 

3  1 

1 

05  1 

7 

1  15 

1  516 

18 

1 

9  1 

Eleven  of  the  surviving  nonequivalent  mutants  are  of 
Type  A,  and  the  other  three  are  of  Type  B.  The  large 
numbers  of  equivalent  mutants  in  the  simple  programs  are  due 
to  "almost  useless"  statements  that  were  included  as  places 
to  insert  branches  without  greatly  affecting  the  number  of 
mutants  generated. 

The  effect  of  adding  complexity  is  very  slight,  and 
can  be  totally  accounted  for  by  the  type  of  uncoupled 
mutants  seen  in  earlier  experiments.  Hence  complexity,  at 
least  in  terms  of  branching,  is  not  a  hinderence  to  mutation 
analysis.  Of  course  these  conclusions  apply  to  a  very 
restricted  definition  of  "complexity".  when  mutation 
analysis  systems  become  avail ible  for  a  structured  language 
like  Pascal,  it  will  be  possible  to  measure  testability  and 
coupling  in  terms  of  other  structural  factors.  In 
particular  a  comparison  of  an  algorithm  coded  using  GOTO 
with  a  comparable  algorithm  using  the  more  socially 
acceptable  constructs  would  be  Interesting. 


(  ■ 
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CHAPTER  V 

, EQUIVALENCE  OF  MUTANTS 

Human  Evaluation  of  Equivalence 

It  was  stated  in  Chapter  III  that  it  would  be  possible 
to  detect  some  equivalent  mutants  automatically,  but  not  all 
of  them.  For  that  reason  we  need  a  mesaure  of  how 
accurately  humans  judge  equivalence.  An  experiment  was 
designed  to  obtain  such  a  measure  under  circumstances 
similar  to  those  under  which  equivalence  judgements  would  be 
made  in  actual  testing.  Programs  3, 4, 5, and  5  were  used. 
For  each  program  the  sequence  of  test  cases  discussed  in 
Chapter  III  was  used  to  eliminate  mutants,  but  testing  was 
stopped  when  the  number  of  mutants  remaining  was 
approximately  twice  the  number  of  equivalent  mutants.  This 
process  eliminated  most  of  the  obviously  inequivalent 
mutants.  It  has  been  our  experience  with  mutation  systems 
that  users  rarely  examine  mutants  closely  with  a  view  toward 
detecting  equivalences  until  the  set  of  mutants  has  been  so 
reduced  by  testing.  From  the  remaining  mutants,  for  each 
program  a  subset  of  fifty  was  selected  randomly  using  a 
pseudo-random  number  generator.  Two  subjects  were  used  in 
the  experiment.  Both  have  been  Involved  in  the  development 
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of  mutation  analysis  systems,  and  are  competent  programmers. 
Neither  had  previously  been  exposed  significantly  to  the 
programs  used  in  the  experiment.  Each  subject  was  given  the 
list  of  mutants  and  the  source  listing  for  each  of  the 
programs,  and  was  instructed  to  mark  each  mutant 
"equivalent"  or  "not  equivalent".  There  was  no  time  limit. 
The  reference  answers  were  prepared  by  the  author  in 
consultation  with  others. 

There  are  two  types  of  errors  that  can  be  made  in 
judging  equivalence.  The  first  type  is  the  marking  of  a 
non-equivalent  mutant  as  equivalent,  and  the  second  is  the 
opposite:  marking  an  equivalent  mutant  as  non-equivalent. 
The  second  type  is  not  too  serious  in  the  process  of 
mutation  analysis,  since  the  mutant  remains  in  the  system 
and  may  be  reconsidered  later.  The  first  type  is  the  major 
problem,  when  a  type  1  error  occurs,  a  non-equivalent 
mutant  which  presumably  could  be  valuable  in  the  testing 
process,  and  which  may  directly  indicate  the  presence  of  an 
error,  is  removed  prematurely  from  consideration. 
Committing  a  type  1  error  increases  the  likelihood  that  an 
erroneous  program  will  be  accepted  as  correct  by  a 
practicioner  of  mutation  anlysis.  The  result  of  the 
experiment  is  shown  in  Table  4.  Far  each  of  the  four 
programs,  the  table  shows  the  number  of  equivalent  and 
non-equivalent  mutants  in  the  sample  of  fifty  mutatns 
present  late  in  the  testing  procedure,  and  the  number  of 
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correct  identifications *  type  1  errors*  and  type  2  errors 
for  the  two  subjects. 


Table  9.  Human  Evaluation  of  Equivalence 


Program 


I 

#  Eq .  1 1  Hot! 


Subject  1 


Subject  2 


I  Co r recti  Type  I Ty pel  Correct 
I  I  1  I  2  I 


I- 


I- 


I* 


Type  I  Type  I 
II  2  1 


3 

1 

20 

1 

30  1 

44 

1 

0 

1 

6  1 

42 

1 

2  1 

6 

1 

4 

I 

21 

1 

29  | 

36 

1 

2 

1 

12  1 

33 

1 

6  1 

11 

1 

5 

1 

20 

1 

30  1 

46 

1 

0 

1 

4  1 

40 

1 

5  1 

5 

1 

5 

1 

13 

1 

37  | 

33 

1 

16 

I 

1  1 

45 

1 

1  1 

4 

1 

Subject  1  was  more  variable  in  accuracy  than  Subject 
2,  but  overall  their  results  were  very  similar.  Subject  1 
identified  79.5%  of  the  mutants  correctly.  Subject  2  was 
correct  or.  30%  of  the  mutants.  In  measuring  type  1  errors* 
the  best  computation  is  probably  the  total  type  1  errors  as 
a  percentage  of  total  non-equivalent  mutants*  since  the 
non-equivalent  mutants  represent  the  potential  type  1 
errors.  Subject  1  made  type  1  errors  on  14.3%  of  the 
non-equivalent  mutants,  and  Subject  2  on  11.1%.  Similarly, 
Subject  1  made  type  2  errors  on  31.5%  of  the  equivalent 
mutants*  and  Subject  2  on  35.1%  of  them. 

The  measure  of  type  1  errors  may  be  high  enough  to 
reduce  confidence  in  mutation  analysis*  if  it  acurately 
predicted  the  frequency  of  such  errors  in  practice.  It 
should  be  remembered*  however,  that  the  subjects  were 
required  to  choose  one  math  or  the  other  for  each  mutant 


with  the  evidence  in  hand  (the  source  listing),  while  a 
tester  in  practice  may  postpone  the  decision  pending  further 


thought  and  testing.  Further,  the  subjects  worked  in 
isolation,  and  were  thus  denied  both  helpful  consultation 
and  the  motivation  of  accountability  for  potential  errors. 
These  would  be  important  factors  in  real-life  testing 
situations.  On  the  other  hand,  the  higher  error  rates  for 
type  2  erors  indicate  that  the  subjects  were  being 
conservative  in  their  judgements,  marking  mutants 
non-equivalent  when  in  doubt. 

Pairs  of  Equivalent  Mutants 

It  might  be  instructive  to  look  at  pairs  of  mutants 
that  are  equivalent  as  first  order  mutants.  These  might  be 
a  source  of  weakness  in  the  mutation  approach.  The  reason 
is  this.  An  equivalent  mutant  is  a  potential  error  about 
which  the  tester  is  saying  "I  don’t  want  to  bother  with 
this;  it  isn't  important."  As  single  mutants,  that  may  be 
true,  but  a  pair  of  equivalent  mutants  may  represent  a  pair 
of  arbitrary  choices  made  by  the  programmer,  which  may  not 
interact  properly.  From  another  point  of  view,  if 
muatatlons  are  considered  not  as  errors  but  as  corrections 
to  a  buggy  program,  it  may  be  that  the  program  needs  two 
corrections,  neither  of  which  improves  the  program  by 
Itself. 
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Consider  the  program  fragment 

P:  A-l 

B»i 

e 

IP  A.NE.O  .AND.  B.EQ.l  ... 

Mutant  programs  PI  with  A«I  changed  to  A»2  and  P2  with  B*l 
changed  to  B*A  might  each  be  equivalent  to  P,  but  P12  with 
both  changes  might  not.  If  PI 2  is  actually  the  correct 
program,  then  it  might  be  possible  for  P  to  pass  first  order 
mutation  analysis,  even  though  it  is  incorrect.  An 
experiment  aimed  at  investigating  this  phenomenon  was 
conducted.  For  each  program,  all  possible  pairs  of  mutants 
marked  equivalent  in  the  testing  process  were  created  and 
run  on  the  test  data.  The  numbers  that  were  killed  were 
determined.  These  numbers  represent  a  lower  bound  on  the 
number  of  pairs  not  equivalent  to  the  original  program, 
since  the  test  data  is  not  perfect.  For  programs  5  and  6, 
the  pairs  were  randomly  sampled  due  to  their  great  number 
and  to  the  long  run  time  of  the  program. 


-  res— : 
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Table  10.  Pairs  of  Equivalent  Mutants 


1  Program 

Number 

Equivalent 

Number  of 
Pairs 

Considered 

1  Number 

1  Killed 
[  by  Data 

1  Percent 

1  Killed 

1 

1  1 

21 

203 

1  0 

1  0.00 

I  2 

47 

1031 

!  4 

1  0.37 

1  3 

106 

5113 

I  36 

1  0.70 

1  4 

95 

4283 

1  6 

1  0.14 

1  5 

228 

5000* 

1  6 

1  0.12** 

1  6 

425 

5000* 

l  27 

1  0.54*** 

*  random  sample 

**  95%  confidence  interval  »  [0.04  ,  0.26] 

***  95%  confidence  interval  “  [0.37  ,  0.73] 


The  results  show  that  less  than  1%  of  the  pairs  of 
equivalent  mutants  are  determined  to  be  nonequivalent  (as 
pairs)  by  this  test  data.  These  measurements  are  lower 
bounds,  since  stronger  test  data  might  distinguish  more 
pairs  from  the  original  program.  However,  the  uniformity  of 
the  results  would  tend  to  raise  our  confidence  that  pairs  of 
first  order  equivalent  mutants  will  not  be  a  major  problem 
for  mutation  analysis  systems. 
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CHAPTER  VI 

SUBSETS  OF  MUTANTS 

Random  Selection  of  Mutants 

The  quadratic  growth  in  the  number  of  mutants  of  a 
program  is  due  to  the  mutant  operators  of  the  substitution 
type.  It  has  been  suggested  that  those  operators  are 
actually  too  strong,  and  that  a  fixed  small  number  of 
substitutions  per  reference  may  produce  almost  the  same 
error-detection  power.  The  reasoning  is  that  the  tester 
•explains"  with  a  test  case  why  the  variable  X  was  used,  for 
example,  not  why  Y  was  not  used  [1],  Hence  random  selection 
of  mutants,  at  least  of  the  substitution  types,  may  be  a  way 
to  bring  the  growth  of  the  number  of  mutants  down  to  the 
linear  range  while  sacrificing  very  little  power.  Table  10 
summarizes  the  results  of  this  study.  The  columns  labeled 
"survive"  indicate  the  counts  of  the  number  of  mutants  out 
of  the  full  100%  that  survive  the  specified  testing 
criterion  and  are  not  equivalent  to  the  original  program. 


Table  11.  Reduced  Power  Mutation  Analysis 


- 

1 

Program  1 

3  Mutants 

#  Mutants 

1  Survive 

1  Survive 

1 

1 

1 

at  10% 

at  100% 

1  "TRAP" 

1  10%  data 

1 

I 

1  ( 

389 

1093 

I  6 

1  0 

1 

1 

2  1 

603 

2814 

1  906 

1  0 

! 

1 

3  1 

1125 

6340 

I  129 

1  2 

1 

1 

4  1 

1509 

7334 

|  97 

1  16 

1 

1 

5  1 

1527 

7957 

I  407 

1  14 

1 

1 

6  1 

4011 

28275 

I  739 

t  66 

I 

It  can  be  seen  that  simply  generating  test  data  to 
cover  all  statements  in  the  program  (TRAP)  is  not  very 
strong,  but  generating  data  to  eliminate  10%  of  the  mutants 
is  almost  as  good  as  using  100%  of  the  mutants.  However, 
the  trend  as  program  size  increases  is  not  quite  what  had 
been  expected.  As  program  size  increases,  10%  mutant 
selection  generates  an  increasing  number  of  mutations  per 
data  reference,  and  should  (intuitively)  produce  a  stronger 
test.  But  the  strength  of  the  test,  measured  by  the 
percentage  of  all  mutants  eliminated,  does  not  increase  with 
program  size,  and  may  actually  be  decreasing.  We  may  again 
consider  these  findings  in  terms  of  implications  for  the 
design  of  future  mutation  analysis  systems.  Experiments  on 
the  coupling  effect  have  already  shown  that  extending 
mutation  from  first  order  to  second  adds  very  little  testing 
power.  Now  it  Is  seen  that  weakening  first  order  mutation 
to  a  subset  of  itself  may  decrease  the  power  of  the  system. 
This  would  Indicate  that  first  order  mutation  is  not  too 


59 


strong,  but  is  rather  the  appropriate  level  of  testing  for  a 
mutation  analysis  system. 

Table  12.  Test  Strength  Using  10%  of  Mutants 


1 

Program  1 

lines  !  Percent  Eliminated 

1 

1 

1 

1  1 

146  | 

100% 

1 

1 

2  I 

153  | 

100% 

1 

1 

3  1 

238  | 

99.97% 

1 

1 

4  1 

321  1 

99.78% 

1 

1 

5  1 

445  | 

99.82% 

1 

1 

6  1 

619  | 

99.77% 

! 

The  test  strengths  are  all  very  good  but  studies  of 
this  effect  with  much  larger  programs  are  needed  to  see  if 
our  intuitions  really  are  valid. 

Efficiency  of  Mutagenic  Operators 

A  second  economy  can  be  gained  if  it  is  found  that 
some  of  the  mutant  operators  provide  only  error  detection 
capabilities  already  covered  by  other  mutant  operators.  In 
particular,  in  Cobol,  if  we  do  not  need  the  data  structure 
mutants,  then  we  can  perform  mutations  on  a  machine  language 
internal  form  (compiled) ,  rather  than  a  higher-level  form 
that  must  be  interpreted. 

For  a  mutatgenic  operator  (or  mutant  type)  to  be 
useful,  it  must  force  the  user  in  some  way  to  produce 
stronger  test  data  than  he  would  without  it.  If  all  of  the 
mutations  produced  by  an  operator  are  extremely  unstable 
(are  eliminated  by  any  test  data  that  executes  the  affected 
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code),  or  if  all  are  equivalent,  then  the  operator  is  not 
providing  useful  information  and  guidance  to  the  tester. 
Let  Nt  be  the  total  number  of  mutants  generated  by  a 
particular  operator,  and  let  Nu  be  the  number  that  are 
eliminated  on  the  first  execution  of  the  affected  code  by  a 
test  data  set,  and  let  Ne  be  the  number  equivalent  to  the 
original  program.  Then  a  measure  of  the  efficiency  of  the 
mutagenic  operator  (for  that  program  and-  that  sequence  of 
test  data  generation)  is  given  by 

(Nt  -  (Nu  +  Ne)  )  /  Nt 

Nt  and  Ne  depend  only  on  the  program  being  considered  and 
the  operators  in  use.  Nu  depends  also  on  the  test  data 
generation  procedure.  It  might  ber  preferable  to  think  of 
the  inefficiency 

(Nu  +  Ne)  /  Nt  ' 

A  reasonable  procedure  for  collecting  operator  efficiency 
data  would  be 

(1)  Select  several  programs  representative  of  the 
application  space  envisioned  for  testing  with  a 
particular  mutation  system. 

(2)  Generate  test  data  just  strong  enough  to 


execute  all  statements.  (i.e.  try  to  produce 
weak  tests,  which  cover  statements  but  do  as 
little  more  as  possible.) 

(3)  Generate  test  data  to  eliminate  all 
nonequivalent  mutants. 

After  such  measurements  have  been  made  on  several 
programs,  and  preferably  even  for  multiple  independent  test 
data  generations  for  each  program,  a  set  of  efficiency 
measurements  for  each  mutagenic  operator  will  be  obtained. 
If  an  operator  consistently  scores  near  zero,  then  the 
deletion  of  that  operator  from  the  mutation  system  would  be 
justified.  If  an  operator  has  a  significant  efficiency 
score  on  any  program  for  any  test  data  generation,  then  that 
operator  is  forcing  the  tester  toward  greater  test  data 
strength  and  should  be  retained. 

There  are  two  limitations  to  this  approach.  The  first 
is  that  it  does  not  consider  interactions  between  operators. 
It  may  be  that  two  operators  each  have  high  efficiencies, 
but  actually  have  the  same  effect,  i.e.  they  require  the 
same  test  data  for  coverage.  In  that  case  one  or  the  other 
may  be  necessary,  but  not  both.  The  efficiency  measures 
will  not  give  us  any  indication  of  this.  In  fact  they  are 
giving  us  just  the  interaction  of  the  TRAP  operator  with  all 
of  the  others,  on  the  assumption  that  we  will  always  want  at 
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least  statement  coverage.  We  could  expand  the  experiment  to 
indicate  mutagenic  operator  dependence  on  any  subset  of 
operators  S  by  replacing  step  2  In  the  procedure  with 

(2)  Generate  test  data  just  strong  enough  to 
eliminate  all  of  the  nonequivalent  mutants 
generated  by  operators  in  S. 

and  by  modifying  the  definition  of  Nu  similarly.  Ideally, 
we  would  measure  the  efficiencies  of  operators  relative  to 
all  possible  subsets,  in  order  to  find  the  minimum  subset 
relative  to  which  no  other  operators  had  significant 
efficiency.  Unfortunately,  this  is  not  feasible.  An 
approximate  operator  selection  procedure  would  be  to  choose 
the  most  efficient  operator  (relative  to  trap),  and  call  it 
01.  Next  choose  the  most  efficient  operator  relative  to 
TRAP  and  01,  and  call  it  02,  and  so  on.  The  procedure  would 
terminate  when  no  operator  had  an  efficiency  above  a 
practical  threshhold. 

A  second  limitation  is  that  the  procedure  works  only 
for  a  given  class  of  programs  from,  which  we  are  sampling. 
Drastically  changing  language  or  even  the  style  in  which  the 
programs  are  written  would  probably  affect  the  choice  of 
efficient  mutagenic  operators.  However  if  we  have  a 
particular  population  of  programs  on  which  we  will  expend 
large  testing  effort,  it  is  possible  to  "fine  tune"  the  set 
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of  operators  for  that  population  of  programs,  by  using  only 
the  operators  that  provide  useful  testing  information. 

The  results  for  the  single  test  data  generation  for 
the  six  programs  are  displayed  in  Table  12. 


Table  13.  Mutagenic  Operator  Efficiencies 


1 

1 

1 

Operator  1 

Program 

1 

1 

1 

2  1 

3  1 

4 

1 

5 

1 

6 

1 

1 

Decimal  I 

* 

1 

0.96  i 

0.30  1 

0.21 

1 

0.33 

1 

0.13 

1 

1 

Occurs  1 

* 

1 

*  1 

# 

0.00 

1 

# 

1 

* 

I 

1 

Insert  I 

0.00 

1 

0.00  1 

0.01  i 

0.00 

1 

0.00 

1 

0.00 

1 

1 

Fill .Si z  1 

0.00 

1 

0.00  I 

0.00  t 

0.00 

1 

0.00 

l 

0.00 

1 

1 

Item  Rev  1 

0.05 

1 

0.04  1 

0.07  i 

0.00 

1 

0.00 

1 

0.01 

1 

1 

Delete  1 

0.00 

1 

0.34  1 

0.00  1 

0.01 

1 

0.04 

1 

0.03 

1 

1 

Go-Perf  1 

* 

1 

*  | 

*  1 

0.00 

1 

* 

1 

0.00 

1 

1 

Perf-Go  j 

0.00 

1 

0.00  I 

0.00  1 

0.08 

1 

0.00 

1 

0.00 

1 

1 

IF  Rev  1 

0.00 

1 

0.67  | 

0.00  1 

0.06 

1 

0.00 

1 

0.00 

1 

1 

Stop  i 

0.00 

1 

0.00  1 

0.00  | 

0.00 

1 

0.00 

1 

0.00 

1 

1 

Thru  1 

0.00 

1 

*  | 

*  1 

0.06 

1 

* 

1 

0.00 

1 

1 

Ar i th  1 

* 

1 

0.75  1 

*  1 

0.04 

f 

0.05 

1 

* 

1 

1 

Compute  1 

* 

1 

0.50  1 

0.25  1 

* 

1 

0.00 

l 

0.00 

1 

1 

Parenth.  1 

* 

I 

*  I 

0.00  1 

* 

1 

0.00 

1 

0.00 

1 

1 

Round  1 

* 

1 

0.44  1 

0.20  1 

0.00 

I 

0.11 

1 

0.17 

1 

1 

Move  Rev  | 

0.00 

1 

0.00  1 

0.00  1 

0.00 

1 

0.04 

1 

0.01 

l 

1 

Logic  1 

0.07 

1 

0.51  1 

0.00  ( 

0.13 

1 

0.24 

1 

0.05 

1 

1 

SFS  1 

0.01 

1 

0.34  | 

0.03  1 

0.01 

1 

0.04 

1 

0.02 

1 

1 

CFC  1 

0.00 

1 

0.25  1 

0.00  1 

0.01 

1 

0.10 

1 

0.04 

1 

1 

CFS  I 

0.00 

1 

0.36  } 

0.03  1 

0.01 

1 

0.05 

1 

0.04 

1 

1 

SFC  1 

* 

1 

0.18  1 

0.00  1 

0.03 

1 

0.09 

1 

0.04 

t 

1 

C  Adjust  { 

0.00 

! 

0.50  1 

0.14  1 

0.06 

1 

0.22 

f 

0.03 

1 

1 

Files  1 

0.00 

1 

*  | 

*  | 

* 

1 

* 

1 

0.00 

1 

*  No  mutants  of  this  type  generated  for  this  program. 

There  is  a  wide  variation  in  efficiencies  between 
programs.  This  is  partly  due  to  the  inexact  test  data 
selection  procedure,  and  partially  due  to  the  inherent 
differences  between  programs.  The  programs  use  different 
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language  constructs  to  perform  different  tasks.  A  mutagenic 
operator  that  focuses  attention  on  one  type  of  construct  Is 
most  useful  in  programs  that  rely  heavily  on  that  construct. 

The  first  five  operators  are  of  special  interest. 
These  data  mutations  force  us  into  interpretive  execution 
using  a  run-time  symbol  table.  If  they  can  somehow  be 
avoided,  then  more  efficient  compiled  execution  is  possible. 
The  first  operator  moves  the  implied  decimal  point  in  a 
numeric  item.  It  is  useful  primarily  in  that  it  forces  the 
tester  to  provide  nonzero  values  for  that  variable.  The 
same  effect  could  be  achieved  by  a  special  mutagenic 
operator  that  requires  a  nonzero  value  at  a  data  reference 
in  the  precedure.  FMS.2  provides  such  an  operator  called 
ZPUSH.  The  second  operator  alters  the  OCCURS  count  in  a 
table  description.  More  investigation  of  programs  using 
tables  is  necessary  before  this  operator  can  safely  be 
deleted,  using  programs  that  rely  more  heavily  on  table 
structures.  Inserting  an  extra  filler  in  a  record  is  of 
little  use,  as  is  altering  the  size  of  a  filler.  Reversing 
two  adjacent  elementary  items  within  a  record  is  sometimes  a 
useful  operation,  but  probably  the  same  effect  is  produced 
by  substituting  one  field  for  another  in  the  procedure 
division.  A  study  of  the  efficiency  of  item  reversal 
relative  to  scalar  substitution  would  be  useful. 

Of  the  procedural  mutations,  changing  a  GO  TO  to  a 
PERFORM  or  vice  versa  usually  provides  no  testing  power. 
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Perhaps  most  o£  the  testing  effect  of  trying  various  path 
alternatives  is  already  achieved  by  simple  statement 
coverage.  Inserting  a  STOP  statement  is  not  helpful  because 
in  most  programs,  files  will  be  left  open,  an  error.  STOP 
insertion  thus  plays  essentially  the  same  role  as  TRAP. 
THRU  clause  alteration,  reparenthisi zation  of  arithmetic 
expressions,  and  the  reversal  of  the  direction  of  a  binary 
MOVE,  and  changing  an  I/O  reference  from  one  file  to  another 
are  rarely  useful.  Probably  these  mutations  too  drastic. 
Errors  this  large  are  must  be  detected  by  any  test  data  that 
exercises  all  of  the  program.  The  errors  we  are  looking  for 
after  completing  basic  statement  coverage  are  subtle  ones. 
The  major  errors  have  already  been  ruled  out. 

A  useful  but  efficient  subset  of  operators  for  a 
compiler-based  mutation  system  might  therefore  be  "Delete" 
(statement  deletion) ,  "IP  rev"  (IP-THSM-ELSE  clause 
reversal)  ,  and  the  substitution  operators  "Arith"  (for 
arithmetic  operator  substitution)  through  "C  Adjust"  (for 
constant  adjustment)  in  Table  12. 
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CHAPTER  VII 

CONCLUSIONS  AND  SUGGESTIONS  FOR  FURTHER  STUD? 

The  results  of  the  experiments  reported  here  basically 
support  mutation  analysis  as  a  testing  discipline.  The 
experiments  on  the  coupling  hypothesis  show  that  test  data 
strong  enough  to  eliminate  simple  errors  is  strong  enough  to 
eliminate  at  least  99.977%  of  random  pairs  of  errors,  and 
99.79%  of  correlated  pairs.  The  failings  of  the  coupling 
effect  for  higher  order  errors  were  too  slight  to  be 
observed.  Program  complexity  does  not  seem  to  create 
problems  for  mutation  analysis.  In  all,  1,090,000  complex 
mutants  were  considered,  and  only  45  of  them*  were 
nonequivalent  changes  not  eliminated  by  the  first  order  test 
data.  All  of  the  observed  failures  of  the  coupling  effect 
were  alterations  of  logical  tests,  and  all  but  one  were 
either  alterations  of  a  comparison  operator  and  one  of  its 
operands,  or  alterations  of  both  operands.  We  could  make  a 
new  mutagenic  operators  "change  a  comparison  operator  and 
one  of  its  operands",  since  this  would  still  be  only 
quadratic  in  program  size.  Call  it  COl.  The  potential 
operator  C02i  "change  both  operands  of  a  comparison",  is 
not  as  attractive,  since  it  would  be  cubic  in  program  size. 
However,  it  is  possible  that  C02  is  coupled  to  COl.  If  an 
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experiment  of  the  efficiency  of  C02  relative  to  C01  (after 
the  fashion  of  Chapter  VI)  should  support  this,  then  adding 
one  more  quadratic  operator  would  correct  almost  all  of  the 
weaknesses  of  the  coupling  effect  that  have  been  observed  in 
this  study. 

Less  conclusive  are  the  results  of  the  study  of  the 
human  evaluation  of  equivalence.  It  was  found  that  during 
the  necessary  step  of  human  judgement  of  mutant  equivalence, 
errors  which  weaken  the  reliability  of  mutation  anlysis  may 
be  made  with  significant  frequency.  At  least  until  more 
sensitive  studies  can  be  made  in  a  true  program  testing 
setting,  practicioners  of  mutation  analysis  should  be 
cautioned  to  be  very  conservative  in  their  marking  of 
equivalence. 

Our  observation  on  the  efficiencies  of  the  various 
mutagenic  operators  indicate  that  mutation  does  not 
inherently  limit  us  to  inefficient  execution  during  testing. 
The  operators  requiring  a  run-time  symbol  table  either  are 
not  useful  or  can  be  simulated  by  other  operators.  The 
operations  that  were  new  for  this  mutation  analysis  system, 
affecting  input  and  output,  provided  no  difficulties,  at 
least  for  the  case  of  read-only  and  write-only  sequential 
files.  Future  systems  and  studies  must  address  more 
flexible  input/output  access  methods. 

In  short,  the  concept  of  matatlon  analysis  has  been 
successfully  transferred  from  Fortran  to  Cobol,  and 
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INTRODUCTION 


The  Cobol  Mutation  System  {CMS.l)  has  been  developed  at  the 
Georgia  Institute  of  Technology  by  Allen  Acree,  Rich 
DeMillo,  Jeanne  Hanks,  and  Fred  Sayward.  It  is  based  in 
part  on  the  Pilot  Mutation  System  (PIMS,  later  renamed 
FMS.l)  for  Fortran  designed  at  Yale  University,  and 
implemented  at  Yale  University,  Georgia  Institute  of 
Technology,  and  the  University  of  California,  Berkely. 

Program  mutation  is  a  method  for  program  testing.  The 
underlying  assumption  is  that  programmers  produce  programs 
that  are,  in  some  sense,  nearly  correct.  The  goal  of  the 
mutation  system  is  to  aid  in  the  selection  of  good  test  data 
by  taking  advantage  of  this  fact.  A  mutation  of  a  program  P 
is  a  program  P'  that  differs  from  P  in  only  a  single  minor 
change,  such  as  substituting  one  variable  for  another  in  an 
assignment  or  changing  a  +  to  a  -  in  an  arithmetic 
expression.  Usually  the  number  of  simple  mutants  of  P  grows 
quadratically  with  the  size  of  P.  Naturally,  some  of  these 
mutations  will  produce  mutant  programs  that  are  functionally 
equivalent  to  the  original,  but  for  the  others  we  should  be 
able  to  find  test  data  that  will  distinguish  between  the 
original  progaram  and  the  mutant. 

CMS.l  is  designed  to  take  as  input  a  fixed  program  P, 
and  to  automatically  produce  mutants  of  it  according  to  a 
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set  of  mutagenic  operators.  The  system  will  then  accept 
test  cases  from  the  user,  run  the  original  program  and  all 
its  mutants  on  it,  and  tell  the  user  how  many  mutants  have 
been  "killed".  (A  mutant  is  killed  when  it  fails  by  program 
fault  or  produces  a  different  output  than  the  original 
program.)  The  aim,  of  course,  is  to  kill  all  the  mutants, 
or  at  least  to  kill  enough  so  that  the  user  is  reasonably 
certain  that  those  remaining  are  functionally  equivalent  to 
the  original  program  and  could  never  be  killed.  At  this 
point  the  user  has  a  set  of  test  data  that  is  sufficiently 
powerful  to  distinguish  between  the  original  program  and  all 
its  simple  (nonequivalent)  mutants.  According  to  the 
coupling  hypothesis  this  test  data  will  also  be  sufficiently 
powerful  to  distinguish  between  the  original  program  and 
most  other  programs  "close"  to  it.  (including  multiple 
mutations.)  This  hypothesis  has  been  proved  for  certain 
classes  of  programs  and  for  certain  definitions  of  "close", 
and  theoretical  work  continues  ir.  this  area.  Recent 
experiments  with  higher  order  mutants  of  Fortran  and  Cobol 
programs  also  support  this  hypothesis. 

Thus  the  user  can,  with  the  aid  of  CMS.l,  produce  test 
data  that  will  distinguish  between  the  program  used  as  input 
and  any  program  "close"  to  it.  Since  we  assume  that  the 
program  used  as  input  is  close  to  a  correct  program,  the 
test  data  will  be  sufficient  to  distinguish  between  the 
input  program  and  the  correct  program,  if  they  are  not 
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equivalent.  So  Che  test  data  will  be  sufficient  to 
demonstrate  program  correctness,  to  a  high  degree  of 
certainty. 

IMPLEMENTATION 

The  user  of  CMS.l  provides  the  name  of  the  file 
containing  the  source  program.  This  program  should  be  in 
the  subset  of  the  Cobol  language  specified  later.  CMS.l 
parses  this  source  program  into  an  internal  form  suitable 
for  interpretive  execution.  This  internal  form  is  also 
suitable  for  "decompilation",  and  the  user  can  be  provided 
with  a  decompiled  version  of  any  statement.  This  decompiled 
statement  may  not  be  textually  identical  to  the  original 
source,  but  it  should  be  equivalent. 

The  system  then  produces  a  file  of  all  mutations  of 
the  original  program.  These  are  stored,  not  as  complete 
programs,  but  rather  as  short  descriptions  of  how  a  mutant 
is  to  be  created.  The  user  is  then  asked  to  provide  a  file 
or  files  of  test  data  for  his  program.  These  files  may  be 
created  outside  CMS.l  using  the  editor,  or  they  may  be 
created  "on  the  fly"  in  CMS.l,  with  editing  capability  being 
restricted  to  backspace  and  line  delete.  However  the  user 
choses  to  provide  the  input  files,  CMS.l  interpretively 
executes  the  original  program  on  this  test  data,  saving  the 
output.  The  user  may  examine  the  output  and  decide  whether 
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or  not  to  accept  it.  If  he  does,  then  the  test  data  is  run 
against  all  enabled  mutants,  and  the  results  of  each  are 
compared  to  the  results  of  the  source.  A  mutant  producing  a 
different  result  is  marked  "killed".  The  user  is  then 
presented  with  a  statistical  summary.  If  he  wishes,  he  may 
also  examine  more  detailed  information  about  the  mutants 
still  living.  He  may  also  review  the  test  cases  accepted  so 
far.  Then  the  cycle  repeats  until  either  an  error  is 

A 

uncovered  in  the  original  program,  or  the  user  is  satisfied 
that  all  remaining  mutants  are  equivalent  to  the  original. 
A  CMS. 1  run  may  be  interrupted  and  continued  later,  with  the 
system  saving  all  information  necessary  for  the  resumption 
of  the  run. 

In  response  to  the  experience  of  trying  to  transfer 
FMS.l  from  one  environment  to  another,  we  have  decided  to 
try  to  do  as  much  as  possible  to  isolate  machine 
dependencies.  At  the  risk  of  possible  inefficiencies,  we 
will  concentrate  references  to  file  access  techniques, 
character  storage,  word  length,  and  such  machine-  and 
operating  system-dependent  features  in  a  few  small  routines. 
For  example,  FMS.l  contained  72  random  access  calls  in  the 
DEC  Fortran  dialect.  Each  of  these  had  to  be  rewritten  as  a 
PRIM3S  call  during  the  transfer  procedure.  In  CMS.l,  all 
random  access  is  through  the  routines  REARAN  and  WRTRAN . 
Those  two  (small)  routines  are  all  that  need  to  be  modified 
to  interface  CMS.l  with  a  different  operating  system.  For 
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efficiency/  some  machine  dependency  is  tolerated  in  the 
interpretive  execution  phase  of  CMS.l/  since  this  is  the 
most  time-consuming  phase  of  the  mutation  process.  However, 
this  dependency  is  kept  to  a  minimum  even  here.  The  buffers 
used  in  interpretively  executing  programs  are  integer  arrays 
of  one  or  two  dimensions.  The  sizes  of  the  arrays  are 
parameters.  We  assume  in  designing  these  arrays  that  a 
single  integer  consists  of  at  least  16  bits.  (i.e. 
integers  are  restricted,  wherever  possible,  to  a  range  of 
+/-  32783.) 


NOTES  ON  THE  C080L  PILOT  MUTATION  SYSTEM 


We  limit  ourselves  to  a  simple  subset  of  the  language. 
We  limit  ourselves  to  ten  sequential  input  files  and 
ten  nonrewindable  Sequential  output  files.  This  should 
be  sufficient  for  such  common  applications  as  making 
sorted  transactions  against  a  sorted  master  file  and 
producing  a  transaction  report  and  an  updated  master 
file.  There  is  a  limit  to  the  amount  of  storage 
allocated  for  each  input  file  and  each  output  file  for 
each  test  case.  The  files  are  "packed”  into  arrays  by 
replacing  each  string  of  repetitions  of  a  single 
character  (such  as  a  string  of  blanks)  by  a  single 
character  and  a  repeat  count.  This  Implies  thrt  the, 
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user  can  submit  larger  test  cases  (more  records)  if  he 
can  arrange  to  use  such  strings  whenever  possible. 

3.  Rather  than  providing  for  a  "predicate  subroutine"  as 
in  FMS.l  we  simply  check  mutant  output  against  original 
program  output  to  determine  whether  they  have  produced 
identical  output  files.  Mutants  can  also  be  eliminated 
by  run-time  faults  such  as  attempting  to  read  an 
unopened  file,  data  fault,  etc.  To  avoid  the  infinite 
loops  that  some  mutations  are  bound  to  create,  a  mutant 
is  eliminated  if  it  executes  more  than  a  certain 
maximum  number  uf  statements.  Currently  this  maximum 
is  set  to  three  times  the  number  of  statements  executed 
by  the  original  program  on  the  test  case. 

4.  Mutations  to  be  performed: 

1  DECIMAL  ALTERATION  -  Move  implied  decimal  in 
numeric  Items  one  place  to  the  left  or  right,  if 
possible. 

2  REVERSE  TWO-LEVEL  TABLE  DIMENSIONS 

3  OCCURS  CLAUSE  ALTERATION  -  Add  or  subtract  one 
from  an  OCCURS  clause. 

4  INSERT  FILLER  -  of  length  one  between  two  items  in 
a  record. 

5  FILLER  SIZE  ALTERATION  -  Add  or  subtract  one  from, 
length. 

6  ELEMENTARY  ITEM  REVERSAL 
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PILE  REFERENCE  ALTERATION 
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9  STATEMENT  DELETION  -  Replace  by  null  operation. 

q  GO  TO  — >  PERFORM 

10  PERFORM  — >  GO  TO 

11  THEN  -  ELSE  REVERSAL  -  Negate  condition. 

12  STOP  STATEMENT  SUBSTITUTION 

13  THRU  CLAUSE  EXTENSION 

14  TRAP  STATEMENT  REPLACEMENT 

15  SUBSTITUTE  ARITHMETIC  VERB 

16  SUBSTITUTE  OPERATOR  IN  COMPUTE 

17  PARENTHESIS  ALTERATION  -  Move  one  parenthesis  one 

place  to  the  left  or  right 

IS  ROUNDED  ALTERATION  -  Change  ROUNDED  to  truncation, 
and  vice  versa. 

1R  MOVE  REVERSAL  -  reverse  direction  of  move  in 
simple  MOVE  A  TO  B,  if  the  result  would  be  legal 
in  Cobol. 

20  LOGICAL  OPERATOR  REPLACEMENT 

21  SCALAR  FOR  SCALAR  REPLACEMENT  -  Substitute  one 

(non-table)  item  reference  for  another,  where  the 
result  would  be  legal. 

22  CONSTANT  FOR  CONSTANT  REPLACEMENT 

23  CONSTANT  FOR  SCALAR  REPLACEMENT 

24  SCALAR  FOR  CONSTANT  REPLACEMENT 

25  NUMERIC  CONSTANT  ADJUSTMENT 


COBOL  SUBSET  ACCEPTED  BY  CMS.l 


IDENTIFICATION  DIVISION. 

PROGRAM-ID.  program-name. 

[AUTHOR,  comment-entry.] 

[INSTALLATION .  comment-entry.] 
[DATE-WRITTEN,  comment-entry.] 
[DATE-COMPILED .  comment-entry.] 

[SECURITY,  comment-entry.] 

[REMARKS .  comment-entry.] 

ENVIRONMENT  DIVISION. 

CONFIGURATION  SECTION. 

[SOURCE-COMPUTER .  comment-entry.] 
[object-computer .  comment-entry.] 
[special-names .  [  [COl  IS  mnemonic-name] 

INPUT-OUTPUT  SECTION. 

FILE-CONTROL. 

[SELECT  file-name  ASSIGN  TO  [iNPUTi  I 
NOTE:  0  <®  1  <-  *» 

DATA  DIVISION. 


OUTPUTl } . 


FILE  SECTION 
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[FD  file-name  RECORD  CONTAINS  Integer  CHARACTERS 
[LABEL  RECORDS  ARE  {  STANDARD  I  OMITTED  }1 
DATA  RECORD  IS  data-name. 
level-number  {data-name  I  FILLER  } 
[REDEFINES  data-name-2] 

[[  PICTURE  I  PIC  }  IS  character-string] 
[OCCURS  integer  TIMES] 


[WORK I NO -STORAGE  SECTION. 

[77  level  entries.] 

[record  entries  .]...] 

NOTE:  Record  entries  are  the  same  as  in  the  file  section, 

except  VALUE  clauses  are  permitted.  Level  88  items 
(condition  names)  are  not  supported.  Legal  PICTURES  are 
signed  and  unsigned  numeric,  edited  numeric,  and 
alphanumeric.  The  USAGE  clause  is  not  supported,  and 
DISPLAY  is  assumed  throughout. 


PROCEDURE  DIVISION. 

[ paragraph-name . ] 

ADD  [ident-1  I  lit-1]  [ident-2  I  lit-2]...  {  TO  I 

GIVING  }  ident-m 

[ROUNDED]  [ON  SIZE  ERROR  imperative-statement]  . 
CLOSE  filename-1  [filename-2]  ... 

COMPUTE  identifier  [ROUNDED]  »  arithmetic-expression 


[ON  SIZS  ERROR  imperative) 

DIVIDE  { ident-1  I  lit-1)  {  INTO  I  BY  }  [ident-2  I 
lit-2) 

[GIVING  ident-3]  [ROUNDED)  [ON  SIZE  ERROR  imperative)  . 
EXIT. 

GO  TO  paragraph-name 

GO  TO  paragraph-name-1  [  [paragraph-name-2]  ... 
DEPENDING  ON  identifier). 

IF  condition  [statement-1  I  NEXT  STATEMENT) 

[ELSE  [statement-2  I  NEXT  STATEMENT  )  ]  . 

NOTE:  logical  operations  AND  and  DR  and  comparisons  a, 
NOT  GREATER  THAN,  etc.,  are  permitted.  Arithmetic 
operations  within  the  conditional  expression  and 
condition  names  are  not  supported.  Sign  tests  and 
class  tests  are  supported. 

MOVE  ident-1  TO  Ident-2  [ident-3]  ... 

MULTIPLY  [ident-1  !  lit-1)  BY  [ident-2  I  lit-2) 

[GIVING  ident-3)  [ROUNDED]  [ON  SIZE  ERROR  imperative]  . 
OPEN  [INPUT  tilename-1  [filename-2)  ] 

[OUTPUT  filename-3  [filename-4]  1 

PERFORM  paragraph-name-1  [THRU  paragraph- name- 2] 

PERFORM  paragraph-name-1  [THRU  paragrapk-name-2] 
[ident-1  I  integer-1)  TIMES . 

PERFORM  paragraph-name-1  [THRU  paragraph-name-2) 

[VARYING  identifier-1  FROM  (identifier-2  I  literal-1) 

BY  [identifier-3  I  literal-2})  UNTIL  condition 


so 


READ  filename  RECORD  [INTO  identifier] 

AT  END  imperative 
STOP  RUN. 

SUBTRACT  [ ident-1  I  lit-1)  [ident-2  I  lit-2)  ...  FROM 
[ident-m  I  lit-m] 

[GIVING  ident-n]  [ROUNDED]  tON  SIZE  ERROR  imperative]  . 
WRITE  record-name  [FROM  identifier-1] 

[AFTER  ADVANCING  {ident-2  I  integer  I  mnemonic]  LINES] 


THE  CMS . 1  RUN 


The  four  phases  of  the  CMS.l  run  are  the  ENTRY  phase, 
the  PRE-RUN  phase,  the  MUTATION  phase,  and  th  POST-RUN 
phase.  The  ENTRY  phase  is  executed  only  when  the  user  first 
enters  the  system.  Thereafter  the  PRE-RUN,  MUTATION,  and 
POST-RUN  phases  are  exected  cyclically. 

I.  The  entry  phase. 

The  session  will  begin  when  the  user  enters  the  system  by 
logging  in  and  typing 
seg  run>cpms 

If  all  is  well,  the  system  will  respond: 

WELCOME  TO  THE  COBOL  PILOT  MUTATION  SYSTEM 
followed  by: 
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PLEASE  ENTER  THE  NAME  OP  THE  COBOL  PROGRAM  FILE: 

The  user  should  do  just  that.  CMS.l  creates  several  working 
files  of  its  own ,  whose  names  are  variations  of  the  source 
file  name  formed'  by  adding  suffixes  to  it.  The  system 
checks  to  see  if  those  working  files  already  exist.  If  they 
do,  the  user  can  either  continue  the  previous  run  on  that 
source  file  where  he  left  off#  or  he  can  start  over  from 
scratch.  Therefore,  if  the  working  files  already  exist,  the 
system  asks: 

DO  YOU  WANT  TO  PURGE  WORKING  PILES  FOR  A  FRESH  RUN  ? 

If  a  new  run  is  needed  the  system  begins  with  the  message 
PARSING  PROGRAM 

A  syntax  error  in  the  source  program  automatically  aborts 
the  CMS.l  run.  The  user  must  correct  the  error  and  re-enter 
the  system.  Errors  are  reported  to  the  user  as  a  source 
program  line  number  and  the  probable  cause. 

The  system  then  issues  the  message 
SAVING  INTERNAL  FORM 
and  asks 

WHAT  PERCENTAGE  OF  THE  SUBSTITUTION  MUTANTS  DO  YOU  WANT  TO 
MAKE? 

Since  medium  to  large  Cobol  programs  may  generate  tens  of 
thousands  of  mutants,  most  of  which  are  simple 
substitutions,  the  user  may  want  to  look  initially  at  only  a 
sampling  of  the  mutants.  It  has  been  our  experience  that 
eliminating  all  of  the  non-equivalent  mutants  in  a  10% 
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sample  gives  test  data  strong  enough  to  eliminate  at  least 
99%  of  all  nonequivalent  mutants. 

CREATING  MUTANT  DESCRIPTOR  RECORDS 


II.  The  pre-run  phase. 

In  this  phase  the  user  supplies  test  data  and  turns  on 

mutants.  The  system  asks 

DO  YOU  WANT  TO  SUBMIT  A  TEST  CASE  ? 

and  the  user  should  respond  YES  or  NO.  The  system  will  ask 
WHERE  IS  f ilenam.e-1  ? 

(if  there  is  a  SELECT  statement  for  that  file) 
to  which  the  user  should  respond  HERE  or  <f iiename> 

If  it  is  HERE,  the  user  enters  the  input  data  directly, 
ending  with  the  control-C  for  end  of  file. 

The  system  then  goes  through  the  same  procedure  for  each 
Input  file  named  in  a  SELECT  statement. 

At  this  point  the  system  will  execute  the  program 
interpretively  on  the  test  input.  After  finishing,  the 
input  and  output  files  will  be  displayed.  The  user  is 
asked : 

IS  THIS  TEST  CASE  ACCEPTABLE  ? 

To  which  the  user  should  respond  YES  or  NO. 

If  YES,  the  test  case  (input  and  output,  along  with  the  time 
used,  record  counts,  and  a  bit  map  of  statements  executed) 
are  catalogued  for  later  use  with  mutant  programs.  If  NO, 
the  test  case  is  purged  from  memory. 

■(  • 


This  process  of  entering  test  cases  Iterates  until  the  user 
states  that  no  more  are  to  be  entered  at  this  time. 


III.  The  Mutation  Phase 

At  this  time  the  system  will  ask 

WHAT  NEW  MUTANT  TYPES  ARE  TO  BE  CONSIDERED  ? 

unles  all  mutant  types  have  already  been  enabled.  The  user 

should  respond  ALL  or  NONE  or  SELECT  or  should  give  the 

numbers  of  the  mutant  types  to  be  used  next.  SELECT  causes 

the  system  to  list  each  type  that  has  not  yes  been 

considered,  and  then  ask  for  types. 

The  list  of  numbers  should  be  terminated  with  the  command 
STOP.  Ranges  of  types  can  be  specified  by  TO.  For  example 
the  reply 
14  20  to  25  stop 

would  enable  the  TRAP  mutants  and  the  data  reference 
substitution  mutants. 

At  this  time  the  test  cases  will  be  run  against  the  mutant 
programs.  The  time  that  this  takes  depends  on  the  number  of 
test  cases  presented,  the  length  and  "density"  of  the 
program,  and  the  types  of  mutants  currently  being 
considered.  For  efficiency,  a  test  case  that  does  not 
execute  a  given  statement  is  not  executed  on  any  mutant 
whose  mutation  is  to  that  statement.  The  mutant  could  never 
be  killed  if  execution  never  reaches  the  affected  statement. 
This  is  the  purpose  of  the  bit  map  saved  with  the  test  case. 


IV.  The  Post-Run  Phase 


After  all  the  test  cases  have  been  executed  for  each  mutant 
still  alive,  the  system  will  display  the  statistics  of  the 
run,  indicating  the  number  of  mutants  created  and  the  number 
still  alive  of  each  type  that  has  been  considered,  the 
percentage  of  each  type  killed,  and  the  number  of  each  type 
marked  equivalent.  Now  the  user  has  a  chance  to  view  the 
mutants  still  remaining  (either  all  of  them,  or  selected 
types)  or  he  can  send  information  about  the  run  to  an  output 
file  for  later  printing.  It  is  while  viewing  the  live 
mutants  at  his  terminal  that  the  user  has  an  opportunity  to 
mark  the  mutants  equivalent.  After  the  live  mutants,  the 
user  has  a  chance  for  a  similar  review  of  the  mutants  marked 
equivalent.  He  can  "unmark"  mutants  at  this  time.  The  user 
also  is  able  to  view  or  print  the  test  cases  at  this  time. 
When  asked  about  either  the  live  or  equivalent  mutants  or 
the  test  cases,  the  user  may  respond  YES  or  NO  or  OUTPUT. 
OUTPUT  means  to  send  the  information  to  the  log  file.  To 
end  the  post-run  phase  the  user  types  either  HALT,  ending 
the  session,  but  saving  the  temporary  files  for  future 
resumption,  or  LOOP  sending  the  system  back  in  a  loop  to  the 
pre-run  phase  to  enter  more  test  data  and/or  consider  new 
mutant  types . 

The  user  may  terminate  the  session  at  any  time  a  command  is 
requested  by  typing  KILL,  but  the  state  of  the  system  files 
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after  such  an  abnormal  termination  is  undefined. 
Continuation  of  the  testing  session  may  not  be  possible. 

The  user  can  receive  an  explanation  of  his  options  at  many 
points  in  the  cycle  by  typing  HELP. 


CMS . 1  AUXILLIARY  FILES 


CMS. 1  creates  several  files  during  execution.  Some  are 
random  access  files  used  for  processing  the  mutants  and  test 
cases,  and  others  are  needed  for  the  restart  capability. 
When  the  user  provides  the  name  of  the  file  containing  the 
test  program,  CMS.l  adds  suffixes  to  that  name  to  create 
names  of  the  auxilliary  files.  For  example  it  the  user 
provided  TEST-PROGRAM-1  as  a  source  program  tile  name,  the 
internal  form  of  the  program  used  by  the  interpreter  and 
decompiler,  would  be  stored  in  the  tile  TEST-PROGRAM-1 . IF. 
The  test  cases  would  be  stored  in  TEST-PROGRAM- 1. TO  and 
TEST-PROGRAM-1 . TS,  and  so  fourth.  One  file  deserves  special 
discussion.  That  is  the  logfile  (TEST-PROGRAM- 1.L0  in  this 
example) .  This  file  contains 

(1)  A  listing  of  the  program,  with  line  numbers. 

(2)  A  statement  about  the  percentage  of  mutants 
created . 

(3)  A  summary  of  test  case  and  mutant  transactions,  in 
the  order  in  which  they  occurred.  Whenever  a  test  case 

i  • 


is  submitted,  a  message  is  logged  about  that,  along 
with  the  filenames  (or  <HERE>)  from  which  the  data  was 
obtained,  and  whether  the  test  case  was  accepted  or 
rejected.  Mutant  types  are  listed  as  they  are  enabled. 

(4)  After  each  mutation  phase  the  status  is  written  to 
the  file,  exactly  as  it  appears  on  the  user's  terminal. 

(5)  An  optional  listing  of  the  live  mutants,  provided 
if  the  user  responds  OUTPUT  to  the  question  about 
viewing  live  mutants. 

(6)  An  optional  listing  of  the  test  cases,  provided  if 
the  user  responds  OUTPUT  to  that  question.  A  listing 
of  the  test  cases  is  strongly  recommended.  When  the 
test  data  is  displayed  on  the  user's  terminal,  lines 
must  be  truncated  to  73  characters.  The  full  lines  are 
placed  in  the  log  file. 

CMS. 1  does  not  automatically  delete  these  working  files 
after  a  run  is  completed.  They  are  retained  for  possible 
resumption  of  testing.  It  is  the  responsibility  of  the  user 
to  delete  the  files  when  they  are  no  longer  needed.  The  log 
file  is  not  automatically  printed,  either.  Each  run  appends 
to  the  end  of  the  file  where  the  previous  run  left  off.  The 
user  must  print  the  file  outside  of  CMS.l  if  he  wants  a  hard 


copy. 
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NATIONAL  BURIAU  OF  STANDARDS- 1963 -A 


PART  I.  FILE  FORMATS 


SOURCE  PROGRAM  <filename> 

The  source  program  is  assumed  to  be  in  a  sequential 
system  file ,  in  the  standard  COBOL  format.  That  is,  columns 
1-6  are  for  the  sequence  number  (and  are  at  this  time 
ignored) ,  column  7  is  either  blank  or  contains  a  hyphen  (for 
the  continuation  of  a  non-numeric  literal)  or  an  asterisk 
(for  a  comment  line).  Information  beyond  column  72  is 
ignored . 

INPUT  FILE  (EXTERNAL) 

The  input  file(s)  can  also  be  supplied  by  the  user  as 
standard  sequential  files.  The  user  only  has  to  tell  CMS.l 
the  name  of  the  file.  The  alternative  is  for  the  user  to 
enter  the  file  directly  while  he  is  in  CMS.l.  When 
requested,  the  user  should  type  the  file  into  the  terminal, 
one  record  per  line,  just  as  if  he  were  punching  a  card 
deck.  The  only  editing  that  can  be  supported  in  this  mode 
is  backspace-erase  (control-fc) ,  and  line-kill  (shift-del) . 
The  end-of-file  is  indicated  with  a  control-c.  It  is  of 
course  possible  to  create  some  input  files  outside  CMS.l 
using  whatever  tools  the  user  has  access  to,  and  to  create 
the  others  "on  the  fly"  in  CMS.l,  if  the  user  wishes. 
Record  sizes  for  input  and  output  files  are  limited  to  150 


characters 


TEST  PILES  (INTERNAL) 

The  internal  test  £iles  will  contain  all  test  cases 
that  have  been  created  at  that  time.  There  are  two  files 
containing  test  information,  the  test  status  file,  and  the 
test  data  file. 

TEST  STATUS  FILE  <f ilename> . ts 

Each  record  of  the  test  status  file  contains  4  2  words. 
The  first  record  contains  global  information, 
word  contents 


1  1  if  INPUTO  is  used  in  the  program 
0  otherwise. 

2  through  20  similar  for  INPUT1  to  INPUTS 

and  OUTPUTO  to  OUTPUT*. 

21  The  total  number  of  test  cases  that 
have  been  defined. 

22  The  number  of  test  cases  that  were 
defined  prior  to  this  pass. 

23  pointer  to  the  next  record  position 
after  the  last,  for  appending. 

24  through  42  Not  used  at  this  time. 

This  record  will  be  followed  by  two  records  for  each 
test  case.  The  first  has  the  format: 

word  contents 


1 


The  starting  position  of  INPUTO  in 


<£ilename>.TD 


2  The  number  of  records  in  INPUTO. 

3  through  40  Similar  for  the  other  files. 

41  The  number  of  statements  executed  by 

the  original  program  on  this  testcase. 

42  Not  used  at  this  time. 

The  second  record  contains  a  bit  map  for  the 
statements  executed  by  this  test  case.  If  this  bit  map  size 
(530=42x15)  is  not  adequate,  the  system,  parameter  TSFRS, 
which  is  currently  set  to  42,  may  be  increased,  and  the 
system  recompiled.  The  extra  •  space  in  the  other  record 
types  will  be  wasted. 

TEST  DATA  FILE  <f ilename>.td 

The  test  data  file  contains  the  actual  test  cases, 
with  the  input  file(s)  first,  followed  by  the  output  file(s) 
of  the  original  program.  These  will  be  in  packed  format 
(see  PACK  and  UNPACK),  with  strings  of  repeated  characters 
replaced  by  single  characters  and  repeat  counts.  The  sizes 
of  each  file  buffer  are  set  by  the  system  parameters  IBSZ 
and  08SZ.  In  systems  where  random  access  files  must  have 
fixed  record  lengths,  IBSZ  must  be  equal  to  OBSZ. 

MUTANT  RECORD  FILE  <f iler.ame> .nr 

The  mutant  records  are  stored  in  binary  format,  at 
four  integers  per  mutant  record.  All  records  for  a 
particular  mutant  type  are  stored  contiguously,  followed  by 
all  records  for  the  next  mutant  type,  etc. 


MUTANT  STATUS  FILE  <f ilenarae> .ms 


The  record  size  for  the  mutant  status  file  is  16 
words.  The  first  section  of  the  file  contains  headers  for 
each  mutant  type. 

mutant  type 

on  or  off  ever  (initially  zero) 
on  or  off  this  run  (  •  "  ) 

msf  record  pointer  for  status  block 

These  may  be  packed  at  four  headers  per  16-word 
record.  All  the  header  blocks  remain  core-resident  during 
the  entire  run. 

The  first  record ,  before  these  headers,  contains  a 
count  of  the  total  number  of  mutants  in  its  first  word.  The 
other  words  are  not  used. 

For  each  mutant  type  there  is  then  a  status  block,  of 
one  record. 

total  mutants  for  this  type 

« 

bit  map  length  in  words 

t 

mrf  pointer  for  the  first  mutant  record  of 
this  type 

number  of  live  mutants 


number  of  dead  mutants 


number  killed  by  trap(*) 

number  killed  by  time-out 

number  killed  by  data  fault 

number  killed  by  Initialization  fault 

number  killed  by  I/O  fault  in  OPEN/CLOSE 

number  killed  by  attempt  to  read  past  EOF 

number  killed  by  writing  too  much 

number  killed  by  output  too  large  for  buffer 

number  killed  by  array  subscripts  out-of-bounds 

number  killed  by  incorrect  output 

number  killed  by  garbage  in  the  code  array 

a 

*  also  includes  attempt  to  execute  beyond  end  of  code, 
such  as  would  happen  if  a  mutation  deleted  the  last  STOP  SUN 
statement;  and  size  errors  where  no  SIZE  ERROR  clause  is 
specified. 

The  status  block  will  be  followed  by  bit  maps. 


!  live  bit  map  I 


I  dead  bit  map  I 


I  equlv.  bit  map  I 


In  all  of  the  bit  maps,  the  first  bit  of  each  word  is 
not  used.  The  bit  maps  are  of  varying  lengths,  depending  on 


the  program  and  on  the  mutant  operators.  The  bit  map 
lengths  are  rounded  up  to  the  nearest  whole- record  size. 
The  record  size  for  this  file  is  the  system  parameter  MSFRS 
(currently  16). 

NOTE— —We  make  no  provision  for  keeping  information 
on  how  each  individual  mutant  was  killed.  We  keep  the  full 
matrix  of  counts  of  mutant  types  versus  kill  mode. 

INTERNAL  FORM  <f ilename>.if 
SYMBOL  TABLE  \ 

I 

STATEMENT  TABLE  I 

I 

CODE  ARRAY  >  binary  copies  from  INFORM 

I  and  HASH 

INIT  l 

l 

HASH  TABLE  / 

INIT  is  the  initial  seqment  of  memory  containing  literals, 
PICTURES,  and  memory  Initialization  information. 

OUTPUT  FILE  <filename>.lo 

This  is  a  sequential  file  containing  information  on 
the  run.  Its  contents  are  controlled  by  the  user,  using  the 
OUTPUT  command.  Typical  contents  would  be  a  listing  of  the 
source  program,  the  test  cases,  the  status  after  each  pass 
through  the  system,  and  a  listing  of  some  or  all  of  the  live 
mutants . 


INITIAL. HASH. PACK 

The  same  as  HASH-TABLE  but  containing  only  the 
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reserved  words  and  their  tokens.  This  is  stored  as  a  packed 
sequential  file.  In  this  case  "packed"  means  that  we  store 
a  count  of  null  records,  followed  by  a  non-null  record, 
followed  by  a  count  of  null  records,  etc.  until  all  records 
(up  to  the  hash  table  size)  are  accounted  for. 


\  \ 


PART  XI. 


INTERNAL  FORM  SPECIFICATIONS 


SYMBOL  TABLE 

The  symbol  table  is  an  IOxn  array  of  integers.  A 
simple  data  item  (group  or  elementary)  is  described  by  one 
row  in  the  array.  A  table  item  is  described  in  two  rows, 
the  second  being  a  dope  vector.  Some  conventions  used  are 
that  £ield  1  in  each  row  (record)  points  to  the  hash  table 
entry,  for  the  name.  If  the  item  has  no  name  (such  as  a 
filler  or  literal) ,  field  1  is  zero.  Field  2  is  always  a 
code  for  the  type  of  the  record.  Its  value  determines  the 
meaning  of  the  other  fields. 

ROW  1:  the  program  name 

Field  1  points  to  the  name,  fields  2  to  4  hold  integers 
for  the  date  of  last  compilation,  and  the  other  fields 
are  not  used. 

ROW  2:  INPUTO 

field- 1  is  used  for  the  hash  table  pointer  to  the  name 
of  the  file  (as  it  Is  known  to  the  program) . 
field-3  is  a  pointer  to  the  symbol  table  entry  for  the 
data  record. 

field-6  is  the  record  length,  (field-1  is  0  if  there 


Is  no  SELECT  clause  for  this  device) 


ROWS  3  through  21 

Like  row  2,  for  INPUT1  to  INPUTS,  OUTPUTO  to  OUTPUTS. 


ROW  22  The  top-of-page  mnemonic  for  the  output  flies 

fleld-1  points  to  name  in  hash,  if  one  has  been 
declared,  otherwise  it  is  zero. 

DATA  ITEMS 


field  meaning 


1  Index  jot  the  Identifier  in  the  hash  table, 
so  that  print  name  can  be  recalled.  For 
FILLERS,  this  is  zero. 

2  A  code  for  the  type  of  the  object. 

1  for  unsigned  numeric  identifier 

2  for  signed  numeric  identifier 

3  for  non-numeric  identifier 

4  for  edited  numeric  item 

5  for  group  item 

3  The  level  number 

4  Pointer  to  the  PICTURE  string  in  program 
memory  for  edited  numeric  items. 

OR  the  decimal  position  (from  right)  for 
unedited  numeric  items. 

OR  not  used. 

5  A  pointer  to  the  start  of  the  item  in  program 
memory.  For  an  item  in  a  table,  this  is  the 
constant  term  in  the  address  calculation. 

6  The  length  of  the  item,  in  characters. 

All  items  are  stored  with  usage  of  DISPLAY. 

The  depth  of  the  item  in  the  table  structure. 
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(0  for  scalars,  1  for  one-level  tablas  or  for 
rows  in  two-level  tables,  2  for  two-level 
tables  entries.) 

8  Pointer  to  VALUE  string  in  program  memory. 


10  The  source  program  line  number  on  which  the  item 

description  began 

SECOND  ROW  FOR  TABLE  ITEMS 

field  meaning 

2  code  »  6 

4  the  multiplier  for  the  first  subscript. 

5  the  multiplier  for  the  second  subscript. 

5  The  maximum  value  for  subscript-1. 

7  The  maximum  value  for  subscript-2. 

8  The  number  of  OCCURances  of  the  item. 

LITERALS  DEFINED  IN  THE  PROCEDURE  DIVISION 
field  meaning 

2  code  =  7  for  numeric  literals 

code  *  3  for  non-numeric  literals 

code  *10  for  the  "twiddle"  of  a  numeric  literal 

4  decimal  position,  for  numeric  literal 

5  pointer  to  value  in  literal  pool 

5  length 

NOTE:  SPACES  and  ZERO  (and  twiddles  of  ZERO)  have  entries 
of  this  format  which  are  present  by  default,  even  if  not 
used  in  the  program. 


PARAGRAPH  NAMES 
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field  meaning 


1  pointer  to  name 

2  code  =  9 

3  statement  table  index  of  first  statement 

4  statement  table  index  of  last  statement 

The  symbol  table  is  stored  in  the  same  order  as  the 
items  are  encountered  in  the  code.  In  particular,  entries 
for  data  items  defined  in  the  DATA  DIVISION  are  stored 
almost  line  for  line  as  they  appear  in  the  source  code,  with 
nesting  being  implicit  in  the  level  numbers  and  the 
sequence.  One  deviation  from  this  is  the  inclusion  of  dummy 
FILLER  entries  of  length  zero  between  elementary  items. 
This  is  to  facilitate  the  mutant  operator  that  inserts 
fillers  to  avoid  having  to  change  procedure  division 
references . 


MEMORY 

The  first  30  characters  of  memory  are  used  as  a 
temporary  arithmetic  register.  Following  that  comes  the 
constant  data  area.  This  area  includes: 

Picture  strings  -  for  edited  numeric  items. 

There  are  3+N  words,  where  N  is  the  length  of  the 
picture  string.  Word  1  Is  the  length  of  the  string; 
word  2  is  the  nunber  of  digit  positions;  and  word  3  is 
the  number  of  digits  to  the  right  of  the  decimal  point. 


••  m 


Mpi^iag-V 


Then  follows  the  picture  string ,  In  A1  format.  An 
editing  MOVE  uses  this  string  to  lnterpretively  execute 
the  MOVE  instruction. 

VALUE  literals 

for  numeric  items  -  word  1  is  the  number  of  digits, 
word  2  is  the  number  of  digits  in  fraction,  and  words  3 
to  n+2  are  the  digits  themselves.  An  operational  sign 
is  coded  in  the  last  word  with  the  last  digit.  for 
nonnumeric  items  -  word  1  is  the  length  N  in 
characters,  and  words  2  to  N+l  are  the  characters,  in 
A1  format. 

Procedure  Division  literals 

Digits  or  characters  only.  Since  these  items  have 
individual  symbol  table  rows,  the  extra  information 
about  length,  decimal  position,  etc,  is  stored  there. 

SPACES  and  ZERO  are  stored  in  positions  after  the 
arithmetic  register  in  a  format  that  can  be  referenced 
either  as  VALUE  or  Procedure  Division  literals, 
depending  on  the  start  pointer. 

After  the  constant  area  comes  the  variable  area.  All 
data  is  storage  on  a  USAGE  IS  DISPLAY  basis,  one  character 
per  word.  Since  some  mutations  change  the  data  structure, 
reallocation  between  executions  is  sometimes  necessary. 

STATEMENT  TABLE 

The  statement  table  is  composed  of  triples  of 
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Integers,  field  1:  the  starting  position  of  an  instruction 
in  the  code  array.  When  a  procedure  division  statement 
is  mutated,  the  original  code  ’is  not  modified. 
Instead,  a  mutated  copy  of  the  instruction  is  created 
and  appended  to  the  end  of  the  code  array.  Field  1  is 
then  modified  to  point  to  this  mutant  copy  of  the 
instruction. 

field  2:  The  line  number  of  the  statement  on  the 
source  listing. 

field  3:  A  value  of  0  means  this  statement  is  a 
continuation  in  a  sentence  (no  period  after  previous 
statement.)  A  value  of  1  means  a  new  sentence.  A 
value  greater  than  1  means  the  beginning  of  an  ELSE 
clause. 

INTERNAL  FORM  OF  PROCEDURE  DIVISION 

Each  Instruction  is  preceeded  by  a  word  containing  the 
length  of  that  instruction. 

meaning  syntax 


MOVE  <MOVXnXsourceXdest-l>. .  ,<dest-n> 

ADD  <ADXrndXsizeXr.Xop-l>. .  .<op-n> 

(rnd  is  0  for  truncation,  1  for  round) 
(size  is  0  if  no  SIZE  ERROR  clause 
has  been  specified,  and  1  if  it  has. 

The  SIZE  ERROR  branch  immediately  follows 
the  current  statement,  followed  by 


( 


ADO-GIVING 


SUBTRACT 

SUB-GIV 

MULTIPLY 

MULT-GIV 

DIVIDE 

DIV-GIV 

COMPUTE 

GO  TO 

GO  TO. «  *  DEPEND 
PERFORM 

PERFORM-UNTIL 

PREFORM-VARYING 


PERFORM-TIMES 


the  no  error  branch.) 

<ADGXrndXsizeXnXop-l>. .  .<op-nXdest> 

<SUXrndXsizeXnXop-l>. .  .<op-n> 

<SUGXrndXsizeXnXop-l>. .  .<op-n><dest> 

<MU><rndXsizeXop-IXop-2> 

<MUGXrndXsizeXop-lXop-2Xdest> 

<DI><rndXsizeXop-IXop-2> 

<DIGXrndXsizeXop-lXop-2Xdest> 

<COXrndXsi  zeXider.  tXari  th .  exp.> 

note:  the  arithmetic  expression 
is  interpreted  by  a  calculator 
subroutine . 

<GOXprocedure> 

<GODXnXproc-l>. .  ,<proc-nXident> 

<  PE>  <  pr  oced  ur  e>  <  proced  ur  e- 2  > 

(procedure-2  may  be  null  if  no 

THRU  clause  is  specified.) 

<PEUXproc-lXproc-2Xcondition> 

<PEVXproe-lxproc-2XidentXf  rom><by> 

<REPlXpl-stmt-ptrXp2-code-ptrXcond.> 

RE PI  is  the  Iteration  control  instruction 
On  return  from  the  PERFORM,  the  control 
goes  to  this  Instruction.  Pl-stmt-ptr  is 
a  statement  table  pointer  corresponding  t< 
the  symbol  table  pointer  proc-1. 
P2-code-ptr  is  a  code  pointer  for  the 
insertion  of  the  return. 

<PET>< proced ur e>< procedure- 2 ><ident> 

<REP2Xcount><startXstop> 


Similar  to  REP1,  but  count  holds  the 
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no  op 
return 


IF 


NEGATED  IF 
OPEN 

CLOSE 

READ 

WRITE 


STOP  RUN 
TRAP 


value  that  was  In  ldent  when  the  PET 
.  was  first  executed. 

Start  and  stop  are  statement  table 
pointers  for  the  perform  range. 

<RET><0> 

<RETXaddr> 

note:  each  paragraph  is  ended  with 
a  "no  op"  statememt.  When  a  PERFORM 
statement  is  executed,  it  first 
changes  the  no  op  at  the  end  of  its 
range  to  a  return  by  inserting  the 
return  address  (in  the  statement 
table)  and  then  transferring  to 
the  beginning  of  the  range. 

When  a  RETURN  is  executed,  it 
transfers  to  the  address  in  the 
instruction  and  also  changes  itself 
to  a  no  op  by  changing  its  address 
field  to  0. 

No  op's  are  also  inserted  when  NEXT 
SENTENCE  is  used  or  implied  in  an  IF 
statement. 

<IFXelse-stmt-ptrXcondition> 
pointer  is  for  transfer  if  condition 
is  false. 

<NIFXelse-stmt-ptrXcondition> 

<OPX1..20> 

(for  which  file) 

<CLX1..20> 

<RE><1 . .10Xf  rom-ident> 

<WRX1.  ,10><f  rom-identXadvance> 

note:  advance  is  pointer  to  symtab. 
Target  is  either  top-o£-page  mne¬ 
monic,  an  identifier,  or  a  numeric 
literal . 

<STOP> 

<TRAP> 
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NOTES  ON  THE  INTERNAL  FORM 

1.  " identifier" ," ident" ,  and  “id",  as  well  as  "op"  are 
pointers  to  symbol  table  entries  describing  identifiers 
or  literals.  The  symbol  table  will  contain  information 
about  type,  length,  location,  etc. 

2.  Any  operand  could  also  be  a  table  reference.  In  this 
case,  instead  of  a  single  integer  we  would  have 
(op](index-l]  or  (op]  (index-1]  [index-2].  The 
interpreter  will  know  from,  the  symbol  table  entries  for 
op  whether  0,1,  or  2  indices  (subscripts)  are  needed  for 
a  valid  reference.  Index-l  (and  index-2)  are  also 
references  via  the  symbol  table  .  to  simple 
( unsubscripted)  variables  or  to  numeric  literals. 

3.  "procedure"  and  "proc"  are  pointers  to  symbol  table 
entries  describing  paragraph  names.  The  symbol  table 
will  contain  pointers  to  the  first  and  last  statements 
in  the  paragraph,  in  the  statement  table. 

MUTANTS 

The  mutant  descriptions  are  stored  in  four  integers. 

The  first  is  the  mutant  type,  and  the  others  (not  all  types 

use  all  four  integers)  are  used  for  auxilliary  information, 

as  detailed  in  PART  III. 
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PART  III.  DETAILS  OP  MUTATION  PROCESS 


MUTANTS 

DECIMAL  Move  implied  decimal  in  numeric  items  one  place  to 
the  left  or  right,  if  possible. 

DIMENS1  Reverse  row  and  column  OCCURS  counts  in  a  two  level 
table. 

DIMENS2  Increment  or  decrement  (by  1)  an  OCCURS  count. 
INSERTF  Insert  a  filler  with  PICTURE  X. 

ALTERF  Alter  a  filler  with  PICTURE  X(r.)  to  X(n-l)  or  X(n+1) 
if  possible. 

REVERSE  Reverse  adjacent  elementary  items  in  a  record. 
FILEREF  Change  a  file  reference  from  one  input  file  to 
another,  etc. 

DELETE  Oelete  a  statement  (change  it  to  a  NO-OP). 

GO-PERF  Change  a  GO  TO  to  a  PERFORM,  unles  the  last 
statement  in  the  paragraph  is  a  stop  or  transfer  of  control 
(in  which  case  it  would  make  r.o  difference,  . 

PERF-GO  Change  a  PERPORM  to  a  GO  TO. 

THENELS  Reverse  the  "then”  and  "else"  clauses  in  an  IF 
(negate  the  condition) . 

STOPINS  Insert  a  STOP  RUN  in  the  program. 

THRUEXT  Extend  the  TRHU  range  of  a  PERFORM. 

TRAP  Change  a  statement  to  a  TRAP,  which  always  fails  when 
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executed.  This  is  £or  statement  coverage  information. 
ARIVERB  Change  one  arithmetic  verb  to  another. 

ARIOPER  Change  an  arithmetic  operator  in  a  COMPUTE 
statement. 

PARENTH  Alter  the  parer.thesi zation  of  an  arithmetic 
expression  in  a  COMPUTE  statement. 

ROUND  Change  rounding  to  truncation ,  or  vice  versa. 

MOVEREV  Reverse  the  direction  of  the  MOVE  in  a  simple  binary 
move/  if  such  would  result  in  a  legal  COBOL  move. 

LOGIC  Change  a  logical  comparison  to  some  other  comparison. 
S-FOR-S  Substitute  one  scalar  (unsubscripted)  named  data 
reference  for  another. 

C-for-C  Substitute  a  constant  (numeric  or  nonnurceric 
literal)  for  another. 

C-FOR-S  Substitute  a  constant  for  a  scalar'. 

S-FQR-C  Substitute  a  scalar  for  a  constant. 

CONSADJ  Increment  or  decrement  a  numeric  literal  by  1  or  by 
1  whichever  is  larger. 


MUTANT  DESCRIPTORS 
DATA  MUTATIONS 

(1)  <DECIMALXsym.tab.locX+l  I  -l><x> 

(2)  <DIM£NSlXsym.tab.locXxXsym.tab.loc.-2> 

for  "reverse  OCCURS  numbers  for  these  two 
locations”.  They  are  assumed  to  be  the 


T 


two  dimensions  for  a  two-level  table. 

(3)  <DIMENS2Xsym.  tab.locXcodeXx) 

where  code  ■  0  for  "add  1  to  OCCURS" 

code  =  1  for  "subtract  1  from  OCCURS" 

(4)  <INSERTF>< symbol  table  locationXxXx) 

(5)  <ALTERFXsym.tab.locX+l  |-lXx> 

(5)  <REVERSEXsym.tab.loc.Xnext .elementary .loc><x> 
INPUT/OUTPUT  MUTATIONS 

(7)  <FlLEREFXstatementXxXnew  file-code> 

CONTROL  STRUCTURE  MUTATIONS 

(8)  <DSLETEXstatement)<yXx> 

(R)  <GO-PERFXstatementXxXx> 

(10)  <PERF-GOXstatementXxXx> 

(11)  <THENELSXstatementXxXx> 

(12)  <STOPINSXstatementXxXx> 

(13)  <THRUEXTXstatementXnew  paragraph  limitXx> 

(14)  <TRAP><statementXxXx> 

PROCEDURAL  MUTATIONS 

(15)  <ARIVERBXstatementXnew  operationXx> 

to  change  ADD  to  SUBTRACT,  etc 

(16)  <ARIOPERXstatementXf ieldXnew  operation) 

to  change  an  operation  in  a  COMPUTE. 

"field"  is  the  location  in  code  relative 
to  the  beginning  of  the  statement,  (op  code 
location.) 

(17)  <PA‘RENTHXstatementXfrom-field><  to- field) 


s  V*  \tz4if*?-  %:*y*~*j 


(13)  <ROUND> <  s  t  a  t  e®  en  tX  xX  x> 

(1R)  <MOVE RE V> < s ta ten*. e‘n  t> < x> < x> 

(20)  <LOGICXstatementXf  ieldXnew  value> 

(21)  <S-FOR-SXstateir.entXf ieldXnew  symtab  loc.> 

(22)  <C-FOR-CXstatementXf  ieldXnew  loc> 

(23)  <C-FOR-SXstateir.entXf  ieldXnew  loc> 

(24)  <S-FOR-CXstatementXf  ieldXnew  loc> 

(25)  <CONSADJXstatementXf  ieldXnew  loc> 

Hence  the  mutants  can  be  stored  in  a  file  of 
4  x  N  integers. 
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The  following  Is  a  serlpt  of  a  CHS.l  run  on  «  program  originally  fron 
the  Amy  SIDPERS  system.  IT)*  program  has  h**n  nodi f lad  somewhat,  mainly  in 
th*  reduction  of  th*  record  sites  to  make  a  better  CRT  display.  The  program 
takes  as  input  two  files ,  representing  and  old  backup  tap*  and  a  new  on*. 
The  output  is  a  summary  of  the  changes,  the  input  files  are  assueed  to  be 
aorted  on  a  key  field.  The  program  has  1195  mutants,  of  which  21  are  easily 
seen  to  be  equivalent  to  th*  original  program.  Initially  tan  tost  cases  were 
generated  to  eliminate  all  of  the  nonequivalent  mutants.  Subsequently  a 
subset  of  five  test  eases  was  found  to  be  adequate  for  the  task.  1h*  entire 
run  took  about  10  minutes  of  clock  time,  and  2  minutes  and  13  seconds  of  CPU 
time  on  th*  PRIME  400.  Not*  that  this  is  a  trace  of  a  terminal  session.  The 
output  of  th*  testcases  la  truncated  to  70  characters  to  avoid  extra 
linefeeds,  the  full  output  is  available  on  hardcopy  to  th*  tester. 


WELCOME  TO  THE  COBOL  PILOT  MUTATION  SYSTEM 

PLEASE  ENTER  THE  NAME  OP  THE  COBOL  PROGRAM  PILE:>log-chang*s 
DO  YOU  WANT  TO  PURGE  WORKING  PILES  POR  A  PRESH  RUN  ?>y*S 
PARSING  PROGRAM 
SAVING  INTERNAL  PORM 

WHAT  PERCENTAGE  OP  THE  SUBSTITUTION  MUTANTS  DO  YOU  WANT  TO  CREATE?>100 
CREATING  MUTANT  DESCRIPTOR  RECORDS 
PRE-RUN  PHASE 

DO  YOU  WANT  TO  SUBMIT  A  TEST  CASE  ?  >program 
PROGRAM  LAST  COMPILED  ON  1  11  80. 
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1  IDENTIFICATION  DIVISION. 

2  PROGRAM-ID.  P0QAACA. 

3  AUTHOR.  CPT  R  W  MOREHEAD. 

4  INSTALLATION.  H0S  USACSC. 

5  DATE-WRITTEN.  CCT  1973. 

6  REMARKS* 

7  THIS  PROGRAM  PRINTS  OUT  A  LIST  OP  CHANGES  IN  THE  ETP. 

8  ALL  ETP  CHANGES  WERE  PROCESSED  PRIOR  TO  THIS  PROGRAM.  THE 

9  OLD  ETP  AND  THE  NEW  ETP  ARE  THE  INPUTS.  BUT  THERE  IS  NO 


10 

FURTHER  PROCESSING  OP  THE  ETP  HERE. 

THE  ONLY  OUTPUT  IS 

n 

LISTING  OP  THE  ADDS,  CHANCES,  AND  DELETES.  THIS  PROGRAM 

12 

POR  HO  USE  ONLY  AND  HAS  NO  APPLICATION  IN  THE  FIELD. 

1  3 

14 

MODIFIED  POR  TESTING  UNDER  CPMS  BY 

ALLEN  ACREE 

15 

JULY,  1979. 

16 

ENVIRONMENT  DIVISION. 

17 

CONFIGURATION  SECTION. 

IP 

SOURCE-COMPUTER.  PRIME. 

19 

OBJECT-COMPUTER.  PRIME. 

20 

INPUT-OUTPUT  SECTION. 

21 

PILE-CONTROL. 

22 

SELECT  OLD- ETP  ASSIGN  INPUT1. 

23 

SELECT  NEW-ETP  ASSIGN  INPUT2. 

24 

SELECT  PRNTR  ASSIGN  TO  OUT PUT 1. 

25 

DATA  DIVISION. 

26 

PILE  SECTION. 

27 

PD  OLD- ETP 

28 

RECORD  CONTAINS  80  CHARACTERS 

29 

LABEL  RECORDS  ARE  STANDARD 

30 

DATA  RECORD  IS  OLD-REC. 

31 

01  OLD-REC. 

32 

03  FILLER 

PIC  X. 

33 

03  OLD-KEY 

PIC  XUS). 

34 

03  FILLER 

PIC  X(67) . 

35 

PD  NEW-ETP 

36 

RECORD  CONTAINS  B0  CHARACTERS 

no 


LABEL  RECORDS  ARE  STANDARD 
DATA  RECORD  IS  NEW-REC. 
NEW-REC. 


40 

03 

PILLER 

PIC 

X. 

41 

03 

NEW-KEY 

PIC 

Xf  12)  . 

42 

03 

FILLER 

PIC 

XCS7). 

43 

PD 

PRNTR 

44 

RECORD  CONTAINS  40  CHARACTERS 

45 

LABEL  RECORDS  ARE  OMITTED 

46 

DATA  RECORD  IS  PR NT-LINE. 

47 

01 

PRNT-LINE 

PIC 

X (40)  . 

48 

WORKING 

-STORAGE  SECTION. 

49 

01 

PRNT-WORK-AREA. 

50 

03 

LINE1 

PIC 

X(30)  . 

51 

03 

LINE2 

PIC 

X (30)  . 

52 

03 

LINE3 

PIC 

X(20) . 

53 

01 

PRNT-OUT-OLD. 

54 

03 

WS-LN-1. 

55 

05  FILLER 

PIC 

X  VALUE  SPACE. 

56 

05  FILLER 

PIC 

XXXX  VALUE  *0  ' . 

S7 

05  LN1 

PIC 

X(30) . 

58 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

59 

03 

WS-LN-2. 

60 

05  FILLER 

PIC 

X  VALUE  SPACE. 

61 

05  FILLER 

PIC 

XXXX  VALUE  'L  '. 

62 

OS  LN2 

PIC 

X(  30)  . 

63 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

64 

03 

WS-LN-3. 

65 

OS  FILLER 

PIC 

X  VALUE  SPACE. 

66 

OS  FILLER 

PIC 

XXXX  VALUE  *D  '. 

67 

05  LN3 

PIC 

X(20) . 

68 

05  FILLER 

PIC 

XXX  VALUE  SPACE. 

69 

01 

PRNT-NEW-OUT. 

70 

03 

NEW-LN-1. 

71 

05  FILLER 

PIC 

XXXXX  VALUE  •  N  • . 

72 

05  N-LNl 

PIC 

X{30) . 

73 

05  FILLER 

PIC 

XXX  VALUE  SPACE. 

74 

03 

NEW-LN-2. 

75 

05  FILLER 

PIC 

XXXXX  VALUE  •  E  '. 

76 

05  N-LN2 

PIC 

X(30) . 

77 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

78 

03 

NEW-LN-3. 

79 

05  FILLER 

PIC 

XXXXX  VALUE  '  W  '. 

80 

05  N-LN3 

PIC 

X (20)  . 

81 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

82 

PROCEDURE  DIVISION. 

83 

OlOO-OPENS. 

OPEN  INPUT  OLD-ETP  NEW-ETP. 

OPEN  OUTPUT  PRNTR. 

0110-0 LD-READ. 

READ  OLD-ETP  AT  END  GO  TO  OISO-OLD-IOP. 
0120-MEW -READ. 

READ  NEW-ETP  AT  END  GO  TO  OITO-NEW-IOP. 
01 30-COMPARES. 

IP  OLD-KEY  -  NEW-KEY 
NEXT  SENTENCE 

ELSE  GO  TO  0140-CK-ADD-DEL. 

IP  OLD-REC  •  NEW-REC 

GO  TO  OllO-OLD-REAO. 

MOVE  OLD-REC  TO  PRNT-WORK-AREA. 

PERPORM  0210-OLD-WRT  THRU  0210-EXIT. 
MOVE  NEW-REC  TO  PRNT-WORK-AREA. 

PERPORM  0200-NW-WRT  THRU  0200-EXIT. 


I 


Ill 


ICO  CO  TO  0110-0 LD-READ. 

101  0140-CK-ADD-DEL. 

102  IF  OLD-KEY  >  NEW-KEY 

103  MOVE  NEW-REC  TO  PRNT-WORX-AREA 

104  PERFORM  0200-NW-WRT  THRU  0200-EXIT 

105  CO  TO  0120-NEW-READ 

106  ELSE  CO  TO  0150-CX-ADD-DEL. 

107  01S0-CK-ADD-DEL. 

109  MOVE  OLD-REC  TO  PRNT-WORX-AREA. 

109  PERFORM  0210-OLD-WRT  THRU  0210-EXIT. 

110  READ  OLD-ETF  AT  END 

111  MOVE  NEW-REC  TO  PRNT-WORK-AREA 

112  PERFORM  0200-NW-WRT  THRU  0200-EXIT 

113  GO. TO  0160-OLD-EOF. 

114  CO  TO  01 30-COMPARES. 

115  0160-OLD-EOF. 

116  READ  NEW-ETF  AT  END  CO  TO  0180-EOJ. 

117  MOVE  NEW-REC  TO  PRNT-WORK-AREA. 

119  PERFORM  0200-NW-WRT  THRU  0200-EXIT. 

119  CO  TO  0160-OLD-EOF. 

120  0170-NEW-EOF. 

121  MOVE  OLD-REC  TO  PRNT-WORK-AREA. 

122  PERFORM  0210-OLD-WRT  THRU  0210-EXIT. 

123  READ  OLD-ETF  AT  END  CO  TO  0190-EOJ. 

124  GO  TO  0170-NEW-EOF. 

125  0180-EOJ. 

126  CLOSE  OLD-ETF  NEW-ETF  PRNTR. 

127  STOP  RUN. 

129  0200-NW-WRT. 

129  MOVE  LINE1  TO  N-LN1. 

130  MOVE  LINE2  TO  N-LN2. 

131  MOVE  LINE3  TO  N-LN3. 

132  WRITE  PRNT-LINE  PROM  NEW-LN-1  AFTER  ADVANCING  2. 

133  WRITE  PRNT-LINE  FROM  NEW-LN-2  AFTER  ADVANCING  1. 

134  WRITE  PRNT-LINE  FROM  NEW-LN-3  AFTER  ADVANCING  1. 

135  0200-EXIT. 

136  EXIT. 

137  0210-OLD-WRT. 

138  MOVE  LINE1  TO  LN1. 

139  MOVE  LINE2  TO  LN2. 

140  MOVE  LINE3  TO  LM3. 

141  WRITE  PRNT-LINE  FROM  WS-LN-1  AFTER  ADVANCING  2. 

142  WRITE  PRNT-LINE  FROM  WS-LN-2  AFTER  ADVANCING  1. 

143  WRITE  PRNT-LINE  FROM  WS-LN-3  AFTER  ADVANCING  1. 

144  0210-EXIT. 

145  EXIT. 

>yaa 

A  ctit  caaa  Cor  this  prog  ran  is  a  pair  of  input  fllas.  In  CMS.l 
thaaa  nay  ba  craatad  outslda  tha  ayataa  and  raforanead  by  naaa.  or  say  bo 
antarad  "on  tha  fly* . 

WHERE  IS  OLD-ETF? 

>le9 

WHERE  IS  NEW-ETF? 

>lc6 

OLD-ETF  PROVIDED  TO  THE  PROGRAM 

11234  56 7890 12IIIIIIIIII OJJJJJJJJJKKKKKKKKKKLLLLLLLLLLMWNMWMWWWMBBBBBBBBBBGGGGG 
J  2  3  4  5678  90 1 2 3YYYYYYYYYYOCCCCGGGCGFFFFFFFFFFODOOODDDDOBSB8S8B88BXXXXXXXXXXEEEEE 

NEW-ETF  PROVIDED  TO  THE  PROGRAM 


11-345678901 200000000000000000000000000000000000000000000000000000000000000000 
J234 567890 ] 23YYYYYYYYYYGGGGGGGGGGFFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXXXXXXXXEEEEE 
34567890 1234UUUUUUUUUUHHHHHHHHHHGGGGGGGGGGDDDDDDDDDDSSSSSSSSSSEEEEEEEEEEAAAAA 

PRNTR  AS  WRITTEN  BY  THE  PROGRAM 

0  II 234567890121 II II II I I IOJJJJJJ 
L  JJJKKKKKKKKKKLLLLLLLLLLNNNNNNN 
D  NNNBBBBBBBBBBGGGGGGC 

N  I 13345678901 200000000000000000 
E  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 
w  00000000000000000000 

0  J234 56 789012 3 YYYYY YYYY YGGGGGGG 
L  GGGFFFFFFFFFFOODOODOOOCSSSSSSS 
0  SSSXXXXXXXXXXEEEEEEE 

V  J234567890123YYYYYYYYYYGGGGGGC 
E  GGGFFFFFFFFFFDODODODDODSSSSSSS 
W  SSSXXXXXXXXXXEEEEEEE 

N  345678901234UUUUUUUUUUHRHHHHH 
E  HHHGGGGGGGGGGOODDOOOOOOSSSSS  S  S 
W  SSSEEEEEEEEEEAAAAAAA 

THE  PROGRAM  TOOK  84  STEPS 
IS  THIS  TEST  CASE  ACCEPTABLE  7  >ys* 

DO  YOU  WANT  TO  SUBMIT  A  TEST  CASE  ?  >no 
MUTATION  PHASE 

WHAT  NEW  MUTANT  TYPES  ARE  TO  BE  CONSIDERED  7  >sslsct 

ENTER  THE  NUMBERS  OF  THE  MUTANT  TYPES  YOU  WANT  TO  TURN  ON  AT  THIS  TIME. 


4 

5 

6 

7 

8 

10 

11 

12 

13 

14 

19 

20 
21 
22 
23 
25 


INSERT  FILLER  TYPE  •••• 

FILLER  SIZE  ALTERATION  TYPE  »•** 
ELEMENTARY  ITEM  REVERSAL  TYPE  ••** 
FILE  REFERENCE  ALTERATION  TYPE 
STATEMENT  DELETION  TYPE  •*** 

PERFORM  — >  GO  TO  TYPE 

THEN  -  ELSE  REVERSAL  TYPE 

STOP  STATEMENT  SUBSTITUTION  TYPE 

THRU  CLAUSE  EXTENSION  TYPE 

TRAP  STATEMENT  REPLACEMENT  TYPE  •••* 

MOVE  REVERSAL  TYPE 

LOGICAL  OPERATOR  REPLACEMENT  TYPE  •••« 
SCALAR  FOR  SCALAR  REPLACEMENT 
CONSTANT  FOR  CONSTANT  REPLACEMENT 
CONSTANT  FOR  SCALAR  REPLACEMENT 
CONSTANT  ADJUSTMENT 


TYPES  7  >4  to  14  Stop 

-  TESTCASE  1  - 

250 

284  CONSIDERED  224  KILLED  60  REMAIN 

MUTANT  STATUS 


TYPE 

TOTAL 

LIVE 

PCT 

EQUIV 

INSERT 

41 

7 

82.93 

0 

FILLSZ 

38 

14 

63.16 

0 

ITEMRV 

21 

0 

100.00 

0 

FILES 

5 

1 

80.00 

0 

DELETE 

54 

13 

75.93 

0 

113 


PER  GO 

7 

2 

71.43  0 

IF  REV 

3 

1 

66.67  0 

STOP 

S3 

10 

81.13  0 

THRU 

8 

2 

75.00  0 

TRAP 

54 

10 

61.46  0 

TOTALS 

284 

60 

78.87  0 

DO  YOU  WANT 

TO  SEE  THE 

LIVE 

MUTANTS?? no 

00  you  WANT  TO  SEE  THE  EOU I VALENT  MUTANTS? >no 
WOULD  YOU  LIKE  TO  SEE  THE  TEST  CASES?>no 
LOOP  OR  HALT  ?  >loop 
PRE*RUN  PHASE 

00  you  WANT  TO  SUBMIT  A  TEST  CASE  ?  >y«S 
WHERE  IS  OLD-ETF? 

>lclS 

WHERE  rs  NEW-ETF? 

>lc5 

OLD-ETF  PROVIDED  TO  THE  PROGRAM 

00000000000121 I I III I I II JJJJJJJJJJKKKKKKKKKKLLLLLLLLLLNNNNNNNNNNBBBBBBBBBBGGGGC 
I 1234 5678901211 I I II I II I J J J J J JJ J JJKKKKKKKKKKLLLLLLLLLLNNNNNNNNNNBBBBBBBBBBGGGGG 
J2345678901 2  3  YYY YYY V VyyGGGGGGGGGGf FFF FPFFFFDDDDDDDDDDSSSSSSSSSSXXXXXXXX XXE  EEEE 

new-etf  provided  to  the  program 

11234  56789017IIIIIIIII I JJ J J JJ J J J JXKKKKKKKKKLLLLLLLLLLNNNNNNNNNNBBBBBBBBBBGGGGG 
J2 34 5678901 2 3YYYYYYYYYYGCGGGCGGGGFFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXXXXXXXXEEEEE 

PRNTR  AS  WRITTEN  BY  THE  PROGRAM 

0  0000000000012IIIIIIIIIIJJJJJJJ 
L  JJJKKKKKKKKKKLLLLLLLLLLNNNNNNN 
0  NNNBBBBBBBBBBGCGCGGG 

THE  PROGRAM  TOOK  44  STEPS 
IS  THIS  TEST  CASE  ACCEPTABLE  ?  >yts 
DO  YOU  WANT  TO  SUBMIT  A  TEST  CASE  ?  >y«» 

WHERE  IS  OLD-ETF? 

>lcl  4 

WHERE  IS  NEW-ETF? 

>lc5 

OLD-ETF  PROVIDED  TO  THE  PROGRAM 

11234  567890 121 1 1 1 II 1 1 1 1 KJ J JJJJJ JJKKKKKKKKKKLLLLLLLLLLNNNNNNNNNNBBBBBBBBBBGGGGG 
J234 5678901 2 3YYYYYYYYYYCGCGGGGGGGFFFFFFFFFFD0DDDDDDDDSSSSSSSSSSXXXXXXXXXXEEEEE 

NEW-ETF  PROVIDED  TO  THE  PROGRAM 

11234  56  789012IIIIIIIII IJJJJJJJJJJKKKKKKKKKKLLLLLLLLLLNNNNNNNNNNBBBBBBBBBBGGGGa 
J234 5478901 23YYYYYYYYYYGGGCCGCGGCFFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXXXXXXXXEEEEE 

PRNTR  AS  WRITTEN  BY  THE  PROGRAM 

0  I 1 234 5678901 211 I I IIII I IKJJJJJJ 
L  JJJKKKKKKKKKKLLLLLLLLLLNNNNNNN 
D  NNNBBBBBBBBBBGGGGGGG 

N  I123456789012IIIII1IIIIJJJJJJJ 
E  JJJKKKKKKKKKKLLLLLLLLLLNNNNNNN 
W  NNNBBBBBBBBBBGGGGGGG 

THE  PROCRAM  TOOK  4B  STEPS 


Afl 


Mi 


IS  THIS  TEST  CASE  ACCEPTABLE  ?  >y«* 

DO  YOU  WANT  TO  SUBHIT  A  TEST  CASE  ?  >y«» 

WHERE  IS  OLD-ETF? 

>lcll 

WHERE  IS  NEW-ETF? 

>lcl 

OLD-ETF  PROVIDED  TO  THE  PROGRAM 
00000000000000000000000000000000000000000000 
NEW-ETF  PROVIDED  TO  THE  PROGRAM 

11234  567890 12IIIIIIIII I JJJ J JJJ JJJKKKKKKKKKKLLLLLLLLLLNNNNNNNNNNBBBBBBBBBBGGGGG 
J234 5678901 23 YYYYYYYYYYGGGGGGGGGGFFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXXXXXXXXEEEEE 
34  5678901234UUUUUUUUUUHHHHHHHHHHGGGGGGGGGGDDDDDDDDDDSSSSSSSSSSEEEEEEEEEEAAAAA 

PRNTR  AS  WRITTEN  BY  THE  PROCRAM 

0  000000000000000000000000000000 
L  00000000000000 
D 

N  1 12345678901 2III!  II II 1 1  J<IJ<IJ<7J 
E  JJJKKKKKKKXKKLLLLLLLLLLNNNNNNN 
W  NNNBBBBBBBBBBGGGGGGG 

N  J234 5678901 23YYYYYYYYYYGGGGGGG 
E  GGGFFFFFFFFFFDDDDDDDDDDSSSSSSS 
W  SSSXXXXXXXXXXEEEEEEE 

N  34567890 1 234UUUUUUUUUUHHHHHHH 
E  HHHGGGGGGGGGGDDDDDDDDDDSSSSSSS 
W  SSSEEEEEEEEEEAAAAAAA 

THE  PROGRAM  TOOK  64  STEPS 
IS  THIS  TEST  CASE  ACCEPTABLE  7  >y#S 
DO  YOU  WANT  TO  SUBMIT  A  TEST  CASE  7  >y*» 

WHERE  IS  OLD-ETF? 

>lcl 

WHERE  IS  NEW-ETF? 

>lcll 

OLD-ETF  PROVIDED  TO  THE  PROGRAM 

I1234567890121IIIIIIIIIJJJJJJJJJJXKKXKKKKKKLLLLLLLLLLNNNNNNNNNNBBBBBBBBBBGGCGG 
J234567890123YYYYYYYYYYGGGCGGGCGGFFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXXXXXXXXEEEEE 
34 567890 1234UUUUUUUUUUHHHHHHHHHHGGGGGGGGGGOODDDDODDDSSSSSSSSSSEEEEEEEEEEAAAAA 

NEW-ETF  PROVIDED  TO  THE  PROGRAM 

oooooooooooooooooooooooooooooooooooooooooooo 

PRNTR  AS  WRITTEN  BY  THE  PROGRAM 

N  000000000000000000000000000000 
E  00000000000000 
w 

O  II 23456789012X1 I I II II I I JJJJJJJ 
L  JJJKKKKKKKKKKLLLLLLLLLLNNNNNNN 
D  NNNBBBBBBBBBBGGGGGGG 


0  J234S67990123YYYYYYYYYYGGGGCGC 
L  GGGFFFFFFFFFFDDDDDDDDDDSSSSSSS 
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0  SSSXXXXXXXXXXEEEEEEE 

0  34 5678901 234UUUUUUUUUUHHHHHHH 

L  HHHGGGGGGGGGGDDDDODDDDDSSSSSSS 
0  SSSEEEEEEEEEEAAAAAAA 

THE  PROGRAM  TOOK  64  STEPS 
IS  THIS  TEST  CASE  ACCEPTABLE  ?  >y«s 
DO  YOU  WANT  TO  SUBMIT  A  TEST  CASE  ?  >no 
MUTATION  PHASE 

WHAT  NEW  MUTANT  TYPES  ARE  TO  BE  CONSIDERED  ?  >#11 

-  TESTCASE  1  - 

2SO 

500 

750 


814  CONSIDERED 
-  TESTCASE  2  - 

640  KILLED 

174 

REMAIN 

234  CONSIDERED 
-  TESTCASE  3  - 

82  KILLED 

152 

REMAIN 

1S2  CONSIDERED 
-  TESTCASE  4  - 

1  KILLED 

131 

REMAIN 

151  CONSIDERED 
-  TESTCASE  5  - 

61  KILLED 

90 

REMAIN 

90  CONSIDERED 

69  KILLED 

21 

REMAIN 

MUTANT  STATUS 


TYPE 

TOTAL  LIVE 

PCT  EQUIV 

INSERT 

41 

3 

92.68  0 

FILLS! 

38 

12 

68.42  0 

ITEMRV 

21 

0 

100.00  0 

FILES 

5 

0 

100.00  0 

DELETE 

54 

1 

90.15  0 

PER  GO 

7 

0 

100.00  0 

IF  REV 

3 

0 

100.00  0 

STOP 

S3 

0 

100.00  0 

THRU 

8 

0 

100.00  0 

TRAP 

54 

0 

100.00  0 

MOVE  R 

13 

0 

100.00  0 

LOGIC 

IS 

1 

93.33  0 

SUBSFS 

704 

4 

99.43  0 

SUBCFC 

12 

0 

100.00  0 

SUBCFS 

58 

0 

100.00  0 

C  ADJ 

12 

0 

100.00  0 

TOTALS 

1098 

21 

98.09  0 

DO  YOU 

WANT  TO  SEE  THE 

LIVE  MUTANTS7>y«S 

THE 

LIVE  MUTANTS 

F OR  EACH  MUTANT  I  HIT  RETURN  TO  CONTINUE.  TYPE  ' STOP*  TO  STOP. 
TYPE  'EQUIV*  TO  JUDGE  THE  MUTANT  EQUIVALENT. 

••••  INSERT  FILLER  TYPE  •••• 

THERE  ARE  3  MUTANTS  OF  THIS  TYPE  LEFT. 

DO  YOU  WANT  TO  SEE  THEM7>y«* 

A  FILLER  OF  LENGTH  ONE  HAS  BEEN  INSERTED  AFTER 
THE  ITEM  WHICH  STARTS  ON  LINE  32 
ITS  LEVEL  NUMBER  IS  3 

> 

A  FILLER  OF  LENGTH  ONE  HAS  BEEN  INSERTED  AFTER 
THE  ITEM  WHICH  STARTS  ON  LINE  33 
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ITS  LEVEL  NUMBER  IS  3 

> 

A  FILLER  OF  LENGTH  ONE  HAS  BEEN  INSERTED  AFTER 
THE  ITEM  NHICH  STARTS  ON  LINE  69 
ITS  LEVEL  NUMBER  IS  3 

> 

FILLER  SIZE  ALTERATION  TYPE  **•* 

THERE  ARE  12  MUTANTS  OF  THIS  TYPE  LEFT. 

DO  YOU  WANT  TO  SEE  THEM?>y«S 


THE 

FILLER 

ON 

LINE 

SB 

HAS 

HAD 

ITS 

SIZE 

DECREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

SB 

BAS 

RAD 

ITS 

SIZE 

INCREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

63 

HAS 

BAD 

ITS 

SIZE 

DECREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

63 

HAS 

BAD 

ITS 

SIZE 

INCREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

69 

HAS 

HAD 

ITS 

SIZE 

DECREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

68 

HAS 

BAD 

ITS 

SIZE 

INCREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

73 

HAS 

HAD 

ITS 

SIZE 

DECREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

73 

HAS 

HAD 

ITS 

SIZE 

INCREMENTED 

BY 

ONE.. 

> 

THE 

FILLER 

ON 

LINE 

77 

HAS 

BAD 

ITS 

SIZE 

DECREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

77 

HAS 

HAD 

ITS 

SIZE 

INCREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

81 

HAS 

BAD 

ITS 

SIZE 

DECREMENTED 

BY 

ONE. 

> 

THE 

FILLER 

ON 

LINE 

81 

HAS 

HAD 

ITS 

SIZE 

INCREMENTED 

BY 

ONE. 

••••  STATEMENT  DELETION  TYPE  •••• 

THERE  ARE  1  MUTANTS  OP  TSIS  TYPE  LEFT. 

DO  YOU  WANT  TO  SEE  THEM?>ytB 
ON  LINE  106  THE  STATEMENT! 

GO  TO  OISO-CX-ADO-DEL 
NAS  BEEN  DELETED. 

> 

••••  LOGICAL  OPERATOR  REPLACEMENT  TYPE  •••* 
THERE  ARE  1  MUTANTS  OP  THIS  TYPE  LEPT. 
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DO  YOU  WANT  TO  SEE  TKEK7>y*« 

OM  LINE  102  TIE  STATEMENT t 

If  OLD-KEY  >  NEW-KEY 
NAS  BEEN  CHANCED  TO< 

XF  OLD-KEY  NOT  <  NEW-KEY 


> 


SCALAR  FOR  SCALAR  REPLACEMENT 

THERE  ARC  4  MUTANTS  OF  THIS  TYPE  LEFT. 

DO  YOU  WANT  TO  SEE  THEM?>y«a 
ON  LINE  129  THE  STATEMENTi 

MOVE  LXNE1  TO  N-LN1 
HAS  BEEN  CHANGED  TO: 

MOVE  NEW-REC  TO  N-LN1 

> 

ON  LINE  129  THE  STATEN ENT t 

MOVE  LINE1  TO  N-LN1 
HAS  BEEN  CHANGED  TO: 

MOVE  PRMT-WORK-ARBA  TO  M-LN1 

> 

ON  LINE  138  THE  STATEMENT: 

MOVE  LINE1  TO  LN1 
HAS  BEEN  CHANGED  TO: 

MOVE  OLD-REC  TO  LM1 

> 

ON  LINE  138  THE  STATEMENT: 

MOVE  LXNE1  TO  LN1 
HAS  BEEN  CHANGED  TO: 

MOVE  PRNT-WORK-AREA  TO  LM1 


> 

DO  YOU  WANT  TO  SEE  THE  EQUIVALENT  MUTANTS? > no 
WOULD  YOU  LIKE  TO  SEE  THE  TEST  CASES7>no 
LOOP  OR  HALT  ?  >to«lt 

••••  STOP 


NUTATION  ON  MUTATION 


This  1*  a  report  of  an  experience  In  ualng  tha  prog ran  Mutation 
aathodology  on  a  production  aoftware  nodula,  naaely,  a  subroutine  In  another 
nutation  ayatea.  The  subject  subroutine  is  NXTLXV  froa  the  Cobol  pilot  nutation 
systea  (CMS.l)  being  developed  by  the  author  at  Georgia  Teeh.  Since  CMS.l  la 
written  in  Fortran,  NXTLXV  was  run  on  the  pilot  nutation  ayatea  for  Fortran 
( ms. l)  which  was  developed  at  yale  University  and  later  transferred  to  Georgia 
Tech. 

Previous  experiaents  of  this  kind  have  taken  a  routine  believed  to 
be  correct,  and  perforaing  nutation  analysis  on  it  to  (1)  Increase  confidence  in 
the  nodule's  correctness,  and  (2)  deaonstrate  that  first  order  nutation  analysis 
Is  feasible  for  real  prograas.  The  current  study  differs  prlaarily  in  that  the 
routine  was  known  to  contain  at  least  one  error.  The  error  had  resisted  the 
usual  debugging  techniques  (selective  traee,  etc.)  Menee  PMS.l  was  being  used 
in  this  instance  not  as  a  teat  data  evaluator,  but  as  a  tool  for  systeaatlc 
debugging,  and,  perhaps  just  as  iaportantly,  as  a  convenient  test  bed  for  a 
subroutine  extracted  fron  its  noraal  environment. 

The  routine  NXTLXV  takes  as  input  the  identifying  number  of  a  nutant 
of  a  given  type,  and  returns  the  nusber  of  the  next  live  nutant,  as  indicated  by 
bit  naps  of  the  live  autants.  The  bit  naps  are  in  general  too  large  to  fit  in 
an  Internal  array,  so  they  are  "paged*  froa  a  randoa  access  disk  file  as  needed. 
Slallar  naps  are  kept  of  the  dead  autants  and  the  autants  judged  to  be 
equivalent. 

The  original  program 
SUBROUTINE  NXTLXV(MTYPE,MUTNO) 

C  FIND  THE  NEXT  LIVE  MUTANT  AFTER  THE  MUTNOth  OP  TYPE  MTYPE 
C  RETURN  THIS  VALUE  IN  NUTNO. 

C  A  VALUE  OF  ZERO  RETURNED  MEANS  NO  MUTANTS  OP  THAT  TYPE  REMAIN  ALIVE 
NOLIST 

SINSERT  ICS057>CPMS.COMPAR>SYSTEN.PAR 
SINSERT  ICS0S7>CPMS.C0MPAR>MAC8INE. SIZES. PAR 
SINSERT  ICS057>CPHS.COMPAR>FILENH.C0N 
SINSERT  ICSOS7>CPMS.COMPAR>TSTDAT.COH 
SINSERT  ICSOS7>CPHS.COMPAR>MSBUF.COM 
LIST 

INTEGER  MTYPE, MUTNO 
INTEGER  I,J,X.L,WORO,BXT 
LOGICAL  ERR 
C  CALL  TIMER1 (33) 

C  ASSUME  THAT  THE  RECORD  CONTAINING  THE  LIVE  BIT  NAPS  FOR 
C  MUTNO  IS  ALREADY  PRESENT,  UNLESS  MUTNO-O 
K-BPW-1 

C  CHECK  TO  SEE  IP  WE  ARE  AT  THE  END  OP  A  PHYSICAL  RECORD 
I F (MUTNO. EQ.O) GOTO  1 
IF(MOO(MUTNO,K*MSFRS) . EQ. 0)GOTO  24 
GOTO  10 

1  CALL  REARAN ( MSP XLE , LX VBUP , MSPRS , LX VPTR , ERR) 

IP (ERR) CALL  ABORTC  (NXTLXV)  ERROR  IN  MUTANT  STATUS  PILE* ,20 
CALL  REARAN ( MSP X LE, EQUBUP, MSPRS, EQUPTR, ERR) 

IP (ERR) CALL  ABORTC (NXTLXV)  ERROR  IN  MUTANT  STATUS  ?XLS',3*) 

CALL  REARAN ( MSP I LE , DEDBUP , MSPRS , DEDPTR , ERR) 

IP (ERR) CALL  ASORT( ' (NXTLXV)  ERROR  IN  MUTANT  STATUS  FILS', 3S) 

CHANG D-. FALSE. 

WORD-1 
BIT-2 
GOTO  20 

10  WORD-MOD( (MUTNO) /(R) .MSPRS) *1 
BXT4I0D(MUTN0,X)*2 
DO  22  J -WORD, MSPRS 
L-LXVBUP(J) 

IF(L.NE.O)GOTO  23 


20 
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MUTNO-MUTNOeK 
I F ( MUTNO . GT . MCT) GOTO  40 
GOTO  22 

23  DO  21  1*I1T,8W 
MUTNO-NUTNO+1 

If (MUTNO. GT.MCT) GOTO  40 
If(AND(L,2**(BPW-I)).NE.O)COTO  30 

21  CONTINUE 
8  IT- 2 

22  CONTINUE 

24  If ( . NOT. CHANGD) GOTO  25 
C  SAVE  OLD  RECORDS 

CALL  WRTRAN ( MSP I LE , LI VB  UP , MS  FRS , L I VPTR , ERR) 

CALL  WRTRAN (MSf I LE, EOUBUf .MSFRS, EQUPTR, ERR) 

CA  LL  WRTRAN ( MSF I LE , DEDBUF , MSFRS . DEDPTR , ERR) 

C  MEED  TO  GET  NEXT  RECORDS 

25  LIVPTR-LIVPTR+MSFRS 
EOUPTR-EQUPTR+MSFRS 
DEDPTR-DEDPTReMSFRS 
GOTO  1 

30  GOTO  0999 

40  MUTNO— 0 

If( .NOT. CHANGD) GOTO  9999 
C  SAVE  OLD  RECORDS 

CALL  WRTRAN ( MSflLE . LIVBUf  , MSf RS , LIVPtR , ERR) 

CALL  WRTRAN ( MSf I LE , EQUBU f , MSfRS , E QU PTR , ERR ) 

CALL  WRTRAN(MSFILE. DEDBUf . MSfRS, DBDfTR, ERR) 

9999  CONTINUE 

C  CALL  TIMER2 

RETURN 
END 

"MS. 1  accepts  a  Ha i tad  subset  at  fortran,  and  thus  ths  program 
could  not  be  tested  directly  as  it  earn*  from  CHS.). 

(1)  PARAMETER  statements  ara  not  accepted,  so  the  parameters 
BPW  (bits  par  word),  MSFRS  <autent  status  file  record  size) 
which  come  fro*  the  SINSERT  blocks  ware  systematically 
replaced  by  convenient  constants,  4  and  4. 

(2)  CALL  stateaents  ara  not  supported.  The  randoa  I/O  routines 
are  simulated  by  arrays  to  be  read  from  and  written  to. 

The  two  TIMER  routines  are  not  essential  and  can  be  ignored. 

(3)  The  functions  MOD  and  AND  are  not  available  and  had  to  be 
simulated. 

(4)  Type  LOGICAL  is  not  available  and  had  to  be  simulated  by 
INTEGER. 

The  modified  program* 

SUBROUTINE  NXTLI V( MUTNO , MCT, LIVBUf , NLB , LL8 , CHANGD) 

C  fIND  THE  NEXT  LIVE  MUTANT  AFTER  THE  MUTNOth  Of  TYPE  MTV PE 
C  RETURN  THIS  VALUE  IN  MUTNO. 

C  A  VALUE  OP  EERO  RETURNED  MEANS  NO  MUTANTS  Of  THAT  TYPE  REMAIN  ALIVE 
INTECER  MUTNO, TEMP 
INTEGER  I,J,L,  WORD,  BIT 

INTEGER  MCT, LIVBUf (4) ,LLB(4) ,NL8(4) , CHANGD 
C  ASSUME  THAT  THE  RECORD  CONTAINING  THE  LIVE  BIT  MAPS  P0R 
C  MUTNO  IS  ALREADY  PRESENT,  UNLESS  MUTNO-O 
C  CHECK  TO  SEE  If  WE  ARE  AT  THE  END  Of  A  PHYSICAL  RECORD 
If (MUTNO. EO.O)GOTO  1 

CCCC  If (MOD (MUTNO, X* MSfRS) . EO. 0)GOTO  24 

If ( (MUTNO/ 12) *12. E0«HUTNO)COTO  24 
GOTO  10 

1  DO  111  I  -  1,4 
111  LIVBUP(I)-NLB( I) 
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CCCCl  CALL  REARAN (MSFILE. LXVBUF, MSFRS, LIVFTR, ERR)  _ 

CCCC  IF (ERR) CALL  ABORT (• (NXTLXV)  ERROR  IN  HUT ART  STATUS  FILE' ,36) 

CCCC  CALL  REARAN { HSFXLE  ,  EQUBUF  , MSFRS , EQUPTR , ERR) 

CCCC  XF(ERR) CALL  ABORT! ' (MXTLXV)  ERROR  XM  RUTART  STATUS  FILE', 36) 

CCCC  CALL  REARAM (MSFILE , DEDBUF .MSFRS , DEDFTR, ERR) 

CCCC  XF(ERR) CALL  ABORT! • (MXTLXV)  ERROR  IM  MUTAMT  STATUS  FILE* ,36) 

CCCC  CHANGD-. FALSE. 

CHANGD-0 
WORD-1 
BIT- 2 
GOTO  20 

CCCC10  WORD-MOD! (MUTNO)/(K) .MSFRS) +1 

10  WORD-  ( (MUTNO/3) -4* ( (MUTMO/3) /4) )  ♦  X 
CCCC  BXT-MOD(NUTMO.K) *2 

BIT-MUTNO-3* (MUTMO/3)  ♦  2 

20  DO  22  J -WORD. 4 
: L-LXVBUF(J) 

IF ( L. ME. 0) GOTO  23 
MUTNO-MUTNO-3 
XF(MUTMO.GT.NCT)GOTO  40 
GOTO  22 

23  DO  21  X-BIT. 4 
HUTNO-NUTNO-1 

I F ( MUTNO . GT. MCT) GOTO  40 
CCCC  IF(AND(L,2**(BFW-I) ) . ME. 0) GOTO  30 

TEMP-L/(2**(4-I)) 

XF(TEMP.NE. (TEMP/2) *2)  GOTO  30 

21  CONTINUE 
BIT-  2 

22  CONTINUE 

CCCC24  IF(. NOT. CRANGD) GOTO  25 

24  I F ( CHANGD. EQ. 0 ) GOTO  25 
C  SAVE  OLD  RECORDS 

CCCC  CALL  WRTRAN ( HSFXLE . LIVBUF , MSFRS . LIVFTR , ERR) 

CCCC  CALL  WRTRAN (MSFILE. EQUBUF . MSFRS . EOU PTR . ERR ) 

CCCC  CALL  WRTRAN (HSFXLE. DEDBUF. MSFRS. DEDFTR. ERR) 

DO  241  1-1.4 
241  LLBd)-LIVBUF(X) 

C  NEED  TO  GET  NEXT  RECORDS 


CCCC25  LIVPTR-LIVPTR-HSFRS 

CCCC 

EQUPTR-EQUPTR -MSFRS 

CCCC 

DEDPTR-DEDPTR-MSFRS 

CCCC 

GOTO  1 

25 

GOTO  1 

30 

GOTO  9999 

40 

MUTNO-O 

CCCC 

XF( . MOT. CHANGD) GOTO 

XF(CHAMGD.EQ.O)  GOTO  9999 
C  SAVE  OLD  RECORDS 

CCCC  CALL  WRTRAN ( MSFILE , LX VBUF, MSFRS . LIVFTR . ERR) 

CCCC  CALL  WRTRAN (RSFILEiEOUBUF, MSFRS, EQUPTR. ERR) 

CCCC  CALL  WRTRAN (MSFILE, DEDBUF, MSFRS, DEDFTR, ERR) 

DO  291  X-1,4 
291  LLS(X)-LXVBUF(X) 

9999  CONTINUE 
RETURN 
END 


A  tree*  of  the  Initial  FRS.l  run  on  this  routine  appeara  below, 
with  eewBontery  in  lower  easo. 

OR,  SEC  RUN>PXHS 
PRE-RUN  PHASE 


m 
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ALL  INPUT  MUST  BE  IN  UPPER  CASE 
ENTER  THE  RAW  PROGRAM  PELS  NAME 
NXTLJV 

DO  YOU  WANT  TO  PURGE  WORKING  PIUS 
FOR  A  FRESH  START? 

TYPE  A  YES  OR  NO  *••• 

YES 

CATECORI2E  FORMAL  PARAMETER  MUTMO 
10 

CATEGORIZE  FORMAL  PARAMETER  MCT 
IN 

CATEGORIZE  FORMAL  PARAMETER  LIVBUF 

CATEGORIZE  FORMAL  PARAMETER  MU 

IN 

CATEGORIZE  FORMAL  PARAMETER  LU 

10 

CATEGORIZE  FORMAL  PARAMETER  CBANGD 

10 

IS  MUTANT  CORRECTNESS  DEPENDENT  ON  A  PREDICATE  SUBROUTINE? 

TYPE  A  YES  OR  NO 
NO 

HOW  MANY  TEST  CASES  ARE  TO  BE  SPECIFIED? 

1 

SPECIFY  TEST  CASE  1 
ENTER  VALUES  FOR 
MUTNO  .MCT  .CHANGD, 

0  f  C 

•  value  of  *0*  Cor  mutno  on  Input  aeans  that  tMa  is  a  now  mutant  type,  and  a 
na«  record  is  required.  MCT  is  the  total  number  of  mutants  of  the  current  type. 
ENTER  4  VALUES  FOR  ARRAY  LIVBUF 

7  7  0  0 

ENTER  4  VALUES  FOR  ARRAY  NU 

0  0  0  0 

nlb  is  the  next  live  buffer.  In  this  case  is  should  be  transferred  to  LIVBUF 
for  use  immediately. 

ENTER  4  VALUES  FOR  ARRAY  LU 

0  0  0  0 

TEST  CASE  NUMBER  1 
PARAMETERS  ON  INPUT 
MUTNO  »  0 

a  minor  bug  in  the  Georqia  Tech  version  of  FMS.l  prevents  the  input  on  the  first 
testcase  from  beinq  echoed. 

PARAMETERS  ON  OUTPUT 


MUTNO 

LIVBUF 

m 

( 

li¬ 

0 

0 

LIVBUF 

< 

ai¬ 

0 

LIVBUF 

( 

se 

0 

LIVBUF 

( 

4)- 

0 

LLB 

( 

1)« 

0 

LLB 

( 

2>- 

0 

LLB 

( 

3)» 

0 

LLB 

c 

«>- 

0 

CHANGD 

■ 

0 

THE  RAW  PROGRAM  TOOK  41  STEPS  TO  EXECUTE  THIS  TEST  CASE 
HIT  RETURN  TO  CONTINUE 

autno*0  on  output  means  that  the  end  of  the  live  mutant  map  for  this  type  has 
been  reached. 
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PLEASE  VERIFY  THAT  DATA  XS  CORRECT 
TYPE  A  YES  OR  NO  ••** 

YES 

WHAT  NEW  TYPES  OP  MUTANTS  ARE  TO  BE  CONSIDERED  ? 

PAN 

thia  stands  Cor  "path  analysts".  Ths  sutant  operator  rsplacas  statasants  with  a 
<trap>  atatanant  which  always  eausas  tha  sutant  to  fall  If  tha  stataaant  is 
axaeutad. 

WHAT  NEW  TYPES  OF  MUTANTS  ARE  TO  BE  CONSIDERED  ? 

NONE 

MUTATION  PHASE 
POST  RUN  PHASE  - 

NUMBER  OF  TEST  CASES  •  1  NUMBER  OF  MUTANTS  -  44 

NUMBER  OF  LIVE  MUTANTS  -  23  PCT  OF  ELIMINATED  MUTANTS  «  47.73 

MUTANT  TYPES  AND  LIVE  MUTANTS  PROFILES 

TYPE  MUT  LIVE*  TYPE  MOT  LIVE*  TYPE  MUT  LIVE*  TYPE  HUT  LIVE* 

PAN  44  23* 

MUTANT  ELIMINATION  METHOD  PROFILE 

METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT* 

TIMED-OUT  0*  REF  UNOVAR  0*  SUBSCR  RNC  0*  ZERO  DIV  0* 

ARTH  FAULT  0*  RDONLY  VAR  0*  TRAP  STMT.  21*  WRONG  ANS  0* 

EQUIV  0* 

POST  RUN  RESULTS 
MUTANTS 

MUTANT  NUMBER  2 

16  IF( (MUTNO/12) *12.EQ.HUTNO)GOTO  24 

STATEMENT  HAS  BEEN  CHANGED  TO 

16  TRAP 

HIT  RETURN  TO  CONTINUE.  TYPE  STOP  TO  FINISH 
TYPE  EQUIV  TO  KILL  MUTANT 

MUTANT  NUMBER  3 

17  GOTO  10 

STATEMENT  HAS  BEEN  CHANGED  TO 
17  TRAP 

HIT  RETURN  TO  CONTINUE.  TYPE  STOP  TO  FINISH 
TYPE  EQUIV  TO  KILL  MUTANT 

MUTANT  NUMBER  10 

32  10  WORD*  ( (MUTHO/3) -4* ( (MUTWO/3) /4) )  ♦  1 

STATEMENT  HAS  BEEN  CHANGED  TO 
32  10  TRAP 

HIT  RETURN  TO  CONTINUE,  TYPE  STOP  TO  FINISH 
TYPE  EQUIV  TO  RILL  MUTANT 

MUTANT  NUMBER  11 

34  BXT-MUTNO-3*<MUTNO/3)  *  2 

STATEMENT  HAS  BEEN  CHANGED  TO 
34  TRAP 

HIT  RETURN  TO  CONTINUE,  TYPE  STOP  TO  PXNXSE 

TYPE  EQUIV  TO  RILL  MUTANT 

STOP 

TYPE  NEXT  COMMAND 
LOOP 

PRE-RUN  PHASE 

SAVING  OUTPUT  FILE  ON  BAROUT 


•f 
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HIT  RETURN  TO  CONTINUE 

HOW  MANY  NEW  TEST  CASES  FOR  THIS  RUN? 

1 

SPECIFY  TEST  CASE  2 
ENTER  VALUES  FOR 
MUTNO  ,MCT  , CHANGD , 

16  0 

ENTER  4  VALUES  FOR  ARRAY  LIVBUF 
7  7  0  0 

ENTER  4  VALUES  FOR  ARRAY  NLB 
0  0  0  0 

ENTER  4  VALUES  FOR  ARRAY  LLB 
0  0  0  0 


TEST  CASE 

NUMBER 

2 

PARAMETERS 

ON  INPUT 

MUTNO 

■ 

1 

MCT 

m 

6 

LIVBUF 

( 

n- 

7 

LIVBUF 

( 

2)- 

7 

LIVBUF 

( 

3)- 

0 

LIVBUF 

( 

4)- 

0 

NLB 

\ 

n- 

0 

NLB 

t 

2)- 

0 

NLB 

( 

35- 

0 

NLB 

( 

4)- 

0 

LLB 

( 

n- 

0 

LLB 

( 

2)- 

0 

LLB 

( 

3)- 

0 

HIT  RETURN 

TO  CONTINUE 

LLB 

( 

4)- 

0 

CHANGD 

m 

0 

PARAMETERS 

ON  OUTPUT 

MUTNO 

m 

2 

LIVBUF 

( 

D- 

7 

LIVBUF 

( 

2)- 

7 

LIVBUF 

( 

3)- 

0 

LIVBUF 

< 

4)- 

0 

LLB 

( 

n- 

0 

LLB 

( 

2)  - 

0 

LLB 

( 

3)- 

0 

LLB 

( 

4)- 

0 

CHANGD 

m 

0 

THE  RAW  PROGRAM  TOOK  16  STEPS  TO  EXECUTE  THIS  TEST  CASE 
HIT  RETURN  TO  CONTINUE 

PLEASE  VERIFY  THAT  DATA  IS  CORRECT 
TYPE  A  YES  OR  NO  **•* 

YES 

WHAT  NEW  TYPES  OF  MUTANTS  ARE  TO  BE  CONSIDERED  ? 

NONE 

REVIEW  PREVIOUS  RUN  RESULTS 
CO 

MUTATION  PHASE 
POST  RUN  PHASE 

NUMBER  OF  TEST  CASES  -  2  NUMBER  OF  MUTANTS  -  44 

NUMBER  OF  LIVE  MUTANTS  -  11  PCT  OF  ELIMINATED  MUTANTS  -  75.00 

MUTANT  TYPES  AND  LIVE  MUTANTS  PROFILES 

TYPE  NUT  LIVE*  TYPE  NUT  LIVE*  TYPE  HUT  LIVE*  TYPE  NUT  LIVE* 

PAN  44  11* 


MUTANT  ELIMINATION  METHOD  PROFILE 


METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT* 
TIMED-OUT  0*  REP  UNDVAR  0*  SUBSCR  RNG  0*  ZERO  DIV  0* 
ARTH  FAULT  0*  RDONLY  VAR  0*  TRAP  STMT  33*  WRONG  ANS  0* 
EOUXV  0* 

POST  RUN  RESULTS 
LOOP 

PRE-RUN  PHASE 

SAVING  OUTPUT  PILE  ON  BAXOUT 
HIT  RETURN  TO  CONTINUE 

ROW  MANY  NEW  TEST  CASES  FOR  THIS  RUN? 

1 

SPECIFY  TEST  CASE  3 
ENTER  VALUES  FOR 
MUTNO  »MCT  , CHANGD , 

10  20  1 

ENTER  4  VALUES  FOR  ARRAY  LIVBUF 
13  0  0 

ENTER  4  VALUES  FOR  ARRAY  NLB 
7  7  0  0 

ENTER  4  VALUES  FOR  ARRAY  LLB 
99  99  99  99 

TEST  CASE  NUMBER  3 
PARAMETERS  ON  INPUT 
MUTNO  -  10 

MCT  •  20 

LIVBUF  {  1)-  1 

LIVBUF  (  2)-  3 

LIVBUF  (  3) ■  0 

LIVBUF  (4)-  0 

NLB  (  1)»  7 

NLB  (  2)«  7 

NLB  (  3)*  0 

NLB  (  4)-  0 

LLB  (  1)«  99 

LLB  (2)-  99 

LLB  f  3)-  99  / 

HIT  RETURN  TO  CONTINUE 

LLB  (4)-  99 

CHANGD  -  1 

PARAMETERS  ON  OUTPUT 
MUTNO  •  14 

LIVBUF  (1)-  7 

LIVBUF  (2)-  7 

LIVBUF  (3)-  0 

LIVBUF  (  4)-  0 

LLB  (  1)«  1 

LLB  (  2)»  3 

LLB  (3)-  0 

LLB  (4)-  0 

CHANGD  -  0 

THE  RAW  PROGRAM  TOOK  S6  STEPS  TO  EXECUTE  THIS  TEST  CASE 
HIT  RETURN  TO  CONTINUE 


An  arror  has  baan  dataetad.  Tha  eorraet  output  Cor  MUTNO  Is  13  instoad  of  14. 
Tha  arror  raaulead  from  choosing  a  starting  point  in  tha  nlddla  of  a  word  of 
sore  blta.  NXTLXV  ordinarily  loopa  through  tha  bits  of  aach  word  looking  for 
tha  naxt  *1*  bit,  but  as  an  afflclaney  saasura.  a  whola  word  Is  cospa rad  to  taro 
bafore  antarlng  tha  loop.  If  all  bits  ars  off.  MUTNO  la  lnerosantad  by  tha  word 
langth.  and  tha  naxt  word  Is  aecassad.  Tha  COrract  algorttha  would  ineraaant 
MUTNO  only  by  tha  n us bar  of  bits  loft  to  bo  axaalnad  In  tha  word.  Tha  only  way 
this  could  aaka  a  dtffaranca  In  tha  original  prog ran  Is  for  NXTLXV  to  bo  cal lad 
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in  such  a  way  a a  to  stop  at  a  *la  bit  in  tha  middle  of  tha  word,  and  than  have 
the  systaa  turn  off  tha  bit  by  raason  of  mutant  fallura  of  equivalence  (outsida 
NXTLIV) ,  and  than  hava  NXTLIV  eallad  again  for  tha  next  nutant  to  ba  eonaidarad. 
This  situation  is  rars  anough  to  frustrata  haphazard  debugging  attaapts,  but 
coanon  anough  to  causa  irritation  in  a  production-si zad  run. 

Tha  correction  is  to  raplaca 

MUTNO  -  MUTNO  ♦  3 

(MUTNO  -  MUTNO  ♦  K  in  tha  original) 

by 

MUTNO  -  MUTNO  ♦  (3- (BIT-2)) 

(MUTNO  -  MUTNO  ♦  (K-(BIT-2))  in  tha  original). 

After  correcting  this  error,  tha  prograa  was  ra-antarad  to  FMS.l  and 
the  testing  cycle  started  over. 

OK,  SEC  RUN>PIHS 
PRE-RUN  PHASE 

ALL  INPUT  MUST  BE  IN  UPPER  CASE 

ENTER  THE  RAW  PROCRAM  FILE  NAME 
NXTLIV 

DO  YOU  WANT  TO  PURGE  WORKING  FILES 

FOR  A  FRESH  START? 

TYPE  A  YES  OR  NO  **•* 

YES 

CATEGORIZE  FORMAL  PARAMETER  MUTNO 
10 


etc. 

HOW  MANY  TEST  CASES  ARE  TO  BE  SPECIFIED? 

1 

SPECIFY  TEST  CASE  1 

ENTER  VALUES  FOR 
MUTNO  ,MCT  , CHANGD, 

0  5  1 

and  so  fourth.  Test  cases  wars  entered  and  executed  correctly  until  all  of  tha 
path  analysis  autants  ware  eliainatad. 

POST  RUN  PHASE 

NUMBER  OF  TEST  CASES  -  8  NUMBER  OF  MUTANTS  -  44 

NUMBER  OF  LIVE  MUTANTS  •  0  PCT  OF  ELIMINATED  MUTANTS  •  100.00 

MUTANT  TYPES  AND  LIVE  MUTANTS  PROFILES 

TYPE  MUT  LIVE*  TYPE  MUT  LIVE*  TYPE  NUT  LIVE*  TYPE  MUT  LIVE* 

PAN  44  0* 

MUTANT  ELIMINATION  METHOD  PROFILE 

METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT* 

TIMED-OUT  0*  REF  UNDVAR  0*  SUBSCR  RNG  0*  ZERO  DIV  0* 

ARTH  FAULT  0*  RDONLY  VAR  0*  TRAP  STMT  44*  WRONG  ANS  0* 

EQUIV  0* 

Thera  is  no  clala  node  that  this  number  of  test  cases  is  an  any  way  minimal. 
Soma  killed  only  one  mutant. 

POST  RUN  RESULTS 
LOOP 

PRE-RUN  PHASE 

SAVING  OUTPUT  FILE  ON  BAXOUT 
HIT  RETURN  TO  CONTINUE 

HOW  MANY  NEW  TEST  CASES  FOR  THIS  RUN? 

0 

WHAT  NEW  TYPES  OF  MUTANTS  ARE  TO  BE  CONSIDERED  ? 

SELECT 
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rOR  EACH  CHOICE,  TYPES  YES.  MO  OR  FINISH 
ARRAY  LIMIT  DEFAULT  INSERTION  * 

YES 

2-DIM  ARRAY  LIMIT  PERMUTATION  * 

NO 

CONSTANT  REPLACEMENT  • 

YES 

SCALAR  VARIABLE  REPLACEMENT  * 

NO 

SCALAR  VAR  FOR  CONSTANT  REPLHT  * 

NO 

CONSTANT  FOR  SCALAR  VAR  REPLHT  * 

NO 

COMPARABLE  ARRAY  NAME  REPLMT  • 

YES 

CONST  FOR  ARRAY  REF  REPLACEMNT  * 

NO 

SCALAR  VAR  FOR  ARR  REF  REPLMT  « 

YES 

ARRAY  REF  FOR  CONST  REPLACEMNT  • 

NO 

ARR  REP  FOR  SCALAR  VAR  REPLMT  * 

NO 


2-DIM  ARRAY  REF  INDEX  PERMUTE  * 

NO 

SCALAR  VAR  INIT  INSERTION  • 

NO 

ARITHMETIC  OPERATOR  REPLACEMNT  * 

YES 

RELATIONAL  OPERATOR  REPLACEMNT  * 

YES 

LOGICAL  CONNECTOR  REPLACEMENT  • 

NO 

ARITHMETIC  precedence  permute  • 

NO 

LOGICAL  PRECEDENCE  PERMUTATION  • 

NO  — • 

GOTO  LABEL  REPLACEMENT  • 

YES 

CONTINUE  STATEMENT  INSERTION  • 

MO 

CONTINUE  STATEMENT  DELETION  * 

NO 

INNER  DO-LOOP  DECOUPLING  • 

NO 

DO-LOOP  INDEX  ALTERATION  • 

YES 

RETURN  STATEMENT  INSERTION  • 

YES 

THESE  MUTANT  TYPES  WERE  ALREADY  ON: 

rnl* 

"S**  MEW  TYPES  OP  MUTANTS  ARE  TO  BE  CONSIDERED  ? 

NONE 

REVIEW  PREVIOUS  RUN  RESULTS 
GO 

MUTATION  PRASE 
POST  RUN  PHASE 

?!  CASES  *  •  NUMBER  Or  MUTANTS  -  299 

NUMBER  OP  LIVE  MUTANTS  •  25  PCT  OP  ELIMINATED  MUTANTS  ■ 

MUTANT  TYPES  AMD  LIVE  MUTANTS  PROFILES 

TYPE  HUT  LIVE*  TYPE  NUT  LIVE*  TYPE  MUT  LIVE*  TYPE  HUT  LIVE* 

A  CA*  14  °*  sr*  «  0*  AOR  84  2* 

ROR  40  10*  CLR  108  9*  PAN  44  0*  RSH  42  4* 


93.73 


MUTANT  ELIMINATION  METHOD  PROFILE 

METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT* 

TIMED-OUT  31*  RE F  UNDVAR  16*  SU8SCR  RNG  19*  EERO  DIV  S* 

ARTH  FAULT  0*  RDONLY  VAR  0*  TRAP  STMT  44*  WRONG  ANS  2S9* 

EOUIV  0* 

POST  RUN  RESULTS 
HALT 

later . . . 

OK,  SEC  RUN>PTMS 
PRE-RUN  PHASE 

ALL  INPUT  MUST  BE  IN  UPPER  CASE 
ENTER  THE  RAW  PROGRAM  FILE  NAME 
NXTLIV 

DO  YOU  WANT  TO  PURGE  WORXIMG  FILES 
FOR  A  FRESH  START? 

TYPE  A  YES  OR  NO  **** 

NO 

after  entering  several  test  esses,  the  situation  was  as  shown t 

MUTATION  PHASE 
POST  RUN  PHASE 

NUMBER  OF  TEST  CASES  -  11  HUMBER  OF  MUTANTS  «  399 

NUMBER  OF  LIVE  MUTANTS  *  9  PCT  OF  ELIMINATED  MUTANTS  •  97.74 

MUTANT  TYPES  AND  LIVE  MUTANTS  PROFILES 

TYPE  MUT  LIVE*  TYPE  MUT  LIVE*  TYPE  MUT  LIVE*  TYPE  HUT  LIVE* 

ALD  3  0*  CAR  14  0*  SPA  63  0*  AOR  84  0* 

ROR  40  1*  GLR  108  7*  PAN  44  0*  RSR  43  1* 

MUTANT  ELIMINATION  METHOD  PROFILE 

METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT* 

TIMED-OUT  ?1*  REF  UNDVAR  16*  SUBSCR  RNG  20*  ZERO  DIV  5* 

ARTH  FAULT  0*  RDONLY  VAR  0*  TRAP  STMT  44*  WRONG  ANS  262* 

EOUIV  12* 

POST  RUN  RESULTS 
LOOP 

PRE-RUN  PHASE 

SAVING  OUTPUT  FILE  ON  BAKOUT 
HIT  RETURN  TO  CONTINUE 

It  was  decided  to  leave  those  nine  alone,  and  consider  all  eutants.  Including 
the  nultltude  of  substitution  Mutants. 

HOW  MANY  NEW  TEST  CASES  FOR  THIS  RUM? 

0 

WHAT  NEW  TYPES  OF  MUTANTS  ARE  TO  BE  CONSIDERED  7 
ALL 

THESE  MUTANT  TYPES  WERE  ALREADY  ONi 
ALD  CRP  CAR  SFA  AOR  ROR  GLR  PAN  DIA  RSR 
REVIEW  PREVIOUS  RUN  RESULTS 
GO 

MUTATION  PRASE 
POST  RUN  PHASE 

NUMBER  OF  TEST  CASES  -  11  NUMBER  OF  MUTANTS  -  1514 

NUMBER  OF  LIVE  MUTANTS  •  50  PCT  OF  ELIMINATED  MUTANTS  -  96.70 

MUTANT  TYPES  AND  LIVE  MUTANTS  PROFILES 

TYPE  MUT  LIVE*  TYPE  MUT  LIVE*  TYPE  MUT  LIVE*  TYPE  MUT  LIVE* 

ALD  3  0*  SVR  368  14*  SFC  306  12*  CFS  180  6* 

CAR  14  0*  CFA  24  0*  SFA  63  0*  AFC  104  1* 
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AFS  128  4*  AOR  84  O*  ROR  40  1*  SLR  108  7* 

PAN  44  0*  CSX  3  3*  CSD  2  1*  RSR  43  1* 

MUTANT  ELIMINATION  METHOD  PROFILE 

METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT* 
TIMED-OUT  45*  REF  UNDVAR  481*  SUBSCR  RNC  98*  ZERO  DXV  25* 
ARTH  FAULT  0*  RDONLY  VAR  0*  TRAP  STMT  44*  WRONG  ANS  759* 
ECUIV  12* 

POST  RUN  RESULTS 


A  cycle  of  (1)  look  at  a  few  llva  autants 

(2)  generate  test  data  to  kill  those  autants 

(3)  execute  autants  on  test  data 

(4)  look  at  aore  autants 

was  followed  several  tlaes  until  the  autant  was  encountered 

MUTANT  NUMBER  689 

45  BIT-2 

STATEMENT  HAS  BEEN  CHANCED  TO 
45  1-2 

The  following  data  was  entered  to  try  to  ellainate  this  autant.  It 
involved  starting  in  the  aiddle  of  a  word ,  and  having  to  go  into  the  next  word 
to  find  the  next  on  bit. 

SPECIFY  TEST  CASE  15 
ENTER  VALUES  FOR 
HUTNO  ,MCT  .CHANCD, 

5  20  0 

ENTER  4  VALUES  FOR  ARRAY  LIVBUP 
0  0  10 

ENTER  4  VALUES  FOR  ARRAY  NLB 
1111 

ENTER  4  VALUES  FOR  ARRAY  LLB 

99  99  99  99 

TEST  CASE  NUMBER  15 


PARAMETERS 

ON 

INPUT 

MUTNO 

• 

5 

MCT 

m 

20 

LIVBUF 

( 

1>- 

0 

LIVBUF 

( 

2)- 

0 

LIVBUF 

( 

31- 

1 

LIVBUF 

( 

4)- 

0 

NLB 

< 

1>- 

I 

NLB 

( 

2>- 

1 

NLB 

c 

31- 

1 

NLB 

( 

41- 

1 

LLB 

( 

1>- 

99 

LLB 

( 

21- 

99 

LLB 

( 

3)* 

99 

HIT  RETURN 

TO  ' 

CONTINUE 

LLB 

( 

4)  - 

99 

CHANCD 

m 

0 

PARAMETERS 

ON 

OUTPUT 

MUTNO 

• 

7 

LIVBUF 

< 

n- 

0 

LIVBUF 

< 

2)- 

0 

LIVBUF 

( 

31- 

1 

LIVBUF 

( 

41- 

0 

LLB 

( 

D- 

99 
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LLB 

( 

2>- 

99 

LLB 

( 

3>- 

99 

LLB 

CHANGD 

( 

m 

4)- 

0 

99 

THE  RAW  PROGRAM  TOOK  23  STEPS  TO  EXECUTE  THIS  TEST  CASE 
HIT  RETURN  TO  CONTINUE 

PLEASE  VERIFY  THAT  DATA  IS  CORRECT 
TYPE  A  YES  OR  NO  **•* 

KILL 

ABORTING  RUN 
•••*  STOP  77777 

The  answer  is  wrong.  Another  error  in  the  program  has  been  found.  Again  it  is 
related  to  the  test  for  an  entire  word  of  zeros.  If  we  start  In  the  alddle  of  a 
word  of  zeros,  the  BIT  pointer  is  not  being  reset  to  2  to  begin  searching  the 
next  word.  The  correction  that  is  needed  is  to  replace 

BIT- 2 

22  CONTINUE 
by 

22  BIT-2 

It  is  Interesting  to  note  that  another  mutant  further  down  in  the  list  does 
exactly  that  —  remove  the  continue  statement  at  the  end  of  a  DO  loop  and  put 
the  label  on  the  next-to-last  statement.  The  error  was  discovered  before  it 
absolutely  had  to  be,  but  it  would  have  been  discovered  eventually  in  any  case. 


OK,  SEC  RUN>PIMS 
PRE-RUN  PHASE 

ALL  INPUT  MUST  BE  IN  UPPER  CASE 

ENTER  THE  RAW  PROGRAM  FILE  NAME 
NXTLIV 

DO  YOU  WANT  TO  PURGE  WORKING  FILES 

FOR  A  FRESH  START? 

TYPE  A  YES  OR  NO  *•«» 

YES 

CATEGORIZE  FORMAL  PARAMETER  MUTNO 
10 

CATEGORIZE  FORMAL  PARAMETER  MCT 
IN 

CATEGORIZE  FORMAL  PARAMETER  LIVBUF 
10 

CATEGORIZE  FORMAL  PARAMETER  NIB 
IN 

CATEGORIZE  FORMAL  PARAMETER  LLB 
10 

CATEGORIZE  FORMAL  PARAMETER  CHANGD 
10 

IS  MUTANT  CORRECTNESS  DEPENDENT  ON  A  PREDICATE  SUBROUTINE? 

TYPE  A  YES  OR  NO  **** 

NO 

HOW  MANY  TEST  CASES  ARE  TO  BE  SPECIFIED? 

15 

SPECIFY  TEST  CASE  1 

ENTER  VALUES  FOR 

MUTNO  , MCT  , CHANGD* 

FILE  TESTNXT 
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1h<  IS  tut  ciui  already  fturatid  ware  run  against  all  nutanta  on  the  latest 
version  of  the  prograa.  These  test  eases  had  been  saved  on  a  file  rather  than 
entered  by  hand  during  the  run. 

MUTATION  PHASE 
POST  RUN  PHASE 

NUMBER  OP  TEST  CASES  •  IS  NUMBER  OP  MUTANTS  -  1SS0 

NUMBER  OP  LIVE  MUTANTS  -  52  PCT  OP  ELIMINATED  MUTANTS  •  96.71 


MUTANT  TYPES  AND  LIVE  MUTANTS  PROFILES 


TYPE 

NUT 

LIVE* 

TYPE 

MUT 

LIVE* 

TYPE  MUT 

LIVE* 

TYPE 

MUT 

LIVE* 

ALD 

3 

0* 

CRP 

68 

5* 

SVR 

368 

4* 

SPC 

306 

10* 

CPS 

180 

6* 

CAR 

14 

0* 

CPA 

24 

0* 

SPA 

63 

0* 

AFC 

104 

0* 

APS 

128 

2* 

AOR 

84 

0* 

ROR 

40 

8* 

GLR 

108 

9* 

PAN 

43 

0* 

CSI 

4 

3* 

CSD 

1 

1* 

RSR 

42 

4* 

MUTANT  ELIMINATION  METHOD  PROFILE 

METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT*  METHOD  COUNT* 
TIMED-OUT  47*  REP  UNDVAR  483*  SUBSCR  RNG  111*  ZERO  DIV  26* 
ARTH  FAULT  0*  ROONLY  VAR  0*  TRAP  STMT  43*  WRONG  ANS  BIB* 
EQUIV  0* 

POST  RUN  RESULTS 


The  cycle  of  killing  a  few  nutants  at  a  tlae  wes  entered  again,  and  sone  Mutants 
were  judged  to  be  equivalent  along  the  way.  One  principal  source  of  equivalent 
nutants  was  the  troublesoae  test  for  a  word  of  zeros.  Its  only  purpose  is  to 
save  the  effort  of  looking  through  the  word  bit  by  bit.  If  the  condition  in  the 
teat  is  replace  by  any  condition  that  is  Identically  .TRUE.,  the  progran  runs  a 
bit  longer  aonetiaes,  but  gets  the  saae  result.  An  exaaple  of  this  is: 

MUTANT  MUMBER  813 

34  IF(L.NE.O)GOTO  23 

STATEMENT  HAS  BEEN  CHANGED  TO 
34  IF<  12.NE.0)  GOTO  23 

Another  source  of  equivalent  autants  is  the  occurrence  of  extra  labels.  For 
exaaple  it  is  easy  to  see  that  GOTO  2S  can  always  be  replaced  with  GOTO  1.  At 
sone  stateaents  in  the  prograa  a  variable  is  guaranteed  to  have  a  particular 
value.  This  generates  equivalent  autants  such  as 

MUTANT  NUMBER  694 

52  DO  241  1*1,4 

STATEMENT  HAS  BEEN  CHANGED  TO 
52  DO  241  I*CHAMCD,4 


In  all,  37  autants  were  judged  to  be  equivalent,  and  the  rest  were  ellainated  by 
test  cases  on  which  the  prograa  perforaed  correctly. 

One  equivalent  autant  actually  turned  out  to  be  an  laprevoaent 
(albeit  s  slight  one)  on  the  original  prograa. 

MUTANT  NUMBER  1362 

36  IP(MUTNO.GT.MCT)GOTO  40 

STATEMENT  HAS  BEEN  CHANGED  TO 
36  IP(  MUTNO.GE.HCT)  GOTO  40 
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MUTANT  STATUS  AFTER  THIS  RUM 

NUMBER  OF  TEST  CASES  •  24  NUMBER  OF  MUTANTS  •  15S0 

NUMBER  OF  LIVE  MUTANTS  •  0  KT  OF  ELIMINATED  MUTANTS  -  100.00 


MUTANT  TYFES  AND  LIVE  MUTANTS  PROFILES 


TYPE  NUT 

LIVE* 

TYPE 

NUT 

LIVE* 

TYPE  NUT 

LIVE* 

TYPE 

NUT 

LIVE* 

ALD 

3 

0* 

CRP 

«S 

0* 

SVR 

348 

0* 

SFC 

306 

0* 

CFS 

ISO 

0* 

CAR 

14 

0* 

CFA 

24 

0* 

SFA 

63 

0* 

AFC 

104 

0* 

AFS 

128 

0* 

ADR 

84 

0* 

ROR 

40 

0* 

GLR 

108 

0* 

PAN 

43 

0* 

CSI 

4 

0* 

CSD 

1 

0* 

RSR 

42 

0* 

MUTANT  ELIMINATION  METHOD  PROFILE 

METHOD  COUNT*  METHOD  COUNT*  METROO  COUNT*  METHOD  COUNT* 
TIMED-OUT  SI*  REF  UNDVAR  4S3*  SUBSCR  RNG  113*  ZERO  DIV  26* 
ARTH  FAULT  0*  RDONLY  VAR  0*  TRAP  STMT  43*  WRONG  ANS  827* 
EQUIV  37* 

POST  RUN  RESULTS 
HALT 


Previous  experience  has  never  found  a  prograa  that  has  passes  autant  analysis 
that  still  contained  an  error.  The  current  prograa  will  be  a  good  test  of  tho 
generality  of  that  esparlenca.  since  this  routine  is  expected  to  continue  in 
service  for  saae  tlae.  It  should  bo  noted  that  not  all  of  the  original  routine 
has  been  tested  by  nutation*  and  no  claims  are  node  for  the  untested  portions. 
But  if  nutation  is  valid*  the  central  logic  of  the  routine  should  now  be 
correct. 


In  many  experimental  settings,  several  factors  are 
thought  to  have  some  possible  relationship  to  a  response 
variable  which  can  be  measured.  Generally  a  linear  model  is 
used . 

X  a  E  +  aA  +  bB  +  ... 

Where  X  =  the  measured  response  variable 
A  =  a  controlled  factor 
a  =  an  unknown  constant 
B  =  another  factor 
b  =  B's  constant 
etc . 

and  E  *  an  "error"  term?  a  random  variable  for  variation 
not  accounted  for  by  any  of  the  controlled  factors.  Some  of 
the  factors  being  considered  may  be  interactions  of  other 
factors . 


1  00 


Analysis  of  variance  is  a  test  of  each  of  the 
hypotheses: 

a»0,  b**0,  . . . 

Suppose  A  is  controlled  to  take  on  just  two  values,  say  0 
and  1,  and  we  want  to  test  the  hypothesis  a*0  (i.e.  A  has 
no  effect) .  Let  SO  be  the  average  value  of  X  for  all 
observations  with  A*0,  and  SI  be  the  average  for  A»l. 
Because  of  the  uncontrolled  random  variation  E,  we  would  not 
expect  SO  to  be  equal  to  Si,  even  if  A  had  no  real  effect  on 
X.  What  we  need  to  do  is  first  estimate  the  variation  due 
to  E,  and  compare  I  SO— SI I  to  the  difference  we  would  thus 
expect  from,  pure  error.  We  can  estimate  the  variation  of  E 
by  making  more  than  one  observation  of  X  at  each  combination 
of  values  of  the  controlled  variables.  These  multiple 
observations  are  called  replicates.  If  we  assume  that  the 
error  term  Is  normally  distributed,  then  we  can  use  the 
tabled  values  of  the  F-distribution  to  decide  whether  or  not 
a  difference  between  SO  and  SI  is  large  enough  that  it  is 
unlikely  that  it  is  the  result  of  pure  chance.  Extensions 
to  more  complicated  cases  are  not  difficult.  Suppose,  for 
example,  that  B  is  controlled  to  ten  values  (say 
0,1,2, ...  ,3) .  Let  Ti  be  the  average  of  the  observations 
with  Bsi.  Then  we  measure  the  variation  possibly  due  to  3 
by  the  sample  variance  of  the  Ti’s,  by  a  sum.-of- squares 
computation.  We  can  compare  that  variation  to  the  variation 
from  E.  If  the  variation  among  the  Ti's  is  much  larger  than 
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that  predicted  from  pure  error,  then  we  conclude  that  B  has 
a  significant  effect.  Again  we  use  values  of  the 
F-distribution  to  determine  the  decision  criteria.  The 
significance  level  of  the  decision  criterion  is  the 
probability  of  concluding  that  the  effect  is  significant,  if 
indeed  it  is  not.  An  excellent  discussion  of  analysis  of 
variance,  along  with  all  necessary  computational  formulas 
and  tables,  may  be  found  in  [23],  or  any  other  good  handbook 
of  experimetal  statistics. 
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Confidence  Intervals 

In  experimental  statistics  we  often  know  the  type  of 
distribution  from  which  we  are  sampling,  but  we  want  to 
determine  some  of  its  controlling  parameters.  For  example, 
we  often  know  (or  assume)  that  we  have  a  normal  (Gaussian) 
distribution,  but  do  not  know  its  mean  or  variance.  We  then 
have  a  two-parameter  family,  and  we  wish  to  establish  the 
parameters.  For  simplicity,  consider  a  one-parameter  family 
f(p).  We  sample  from  f  by  making  several  observations  of 
objects  in  the  distribution,  and  estimate  p  from  the 
observations.  The  mathematical  form  of  the  estimate  depends 
on  the  form  of  the  family.  If  f  were  a  class  or  normal 
distributions  all  with  variance®!,  and  p  were  the  mean,  then 
the  best  estimate  of  p  would  be  the  arithmetic  mean  of  the 
observations.  If  f  were  the  class  of  uniform  distributions 
on  the  interval  (p,l),  then  a  good  estimate  for  p  would  be 
the  minimum  observation.  In  any  case,  once  we  have  the 
estimate,  we  like  to  ask  ourselves  how  accurate  the  estimate 
is.  The  question  is  often  answered  with  a  confidence 
interval.  If  we  sample  from  f  and  estimate  p*p,  we  like  to 
also  say  "there  is  a  95%  probability  that  PO  i  P  ^  pi", 
where  pO  and  pi  are  also  computed  from  the  observations. 
The  interpretation  of  this  statement  is  Important,  p  is  not 
a  random  variable;  either  it  is  In  the  interval  or  it  is 
not.  The  random  variables  are  pO  and  pi.  A  more  accurate 
statement  would  be  "experimental  procedure  S  produced  the 
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interval  [pO,pl],  and  there  Is  a  95%  probability  that  S  will 
produce  an  interval  containing  the  true  value  o£  p" . 

The  family  of  distributions  underlying  the  coupling 
experiments  is  the  binomial  distribution. 

n!  k  n-k 

P  (k)  - -  p  (1-p) 

p  k!  (n-k)  I 

if  k  is  an  integer  between  0  and  n 

p  (k)=0  otherwise. 

P 

Here  n  is  the  sample  size,  k  is  .the  number  of  successes  in 
the  sample,  and  p  is  the  probability  of  success  on  any  one 
observation.  ("Success"  here  can  mean  anything  we  want.) 
In  our  experiments,  n  is  on  the  order  of  10,000  to  50,000, 
and  p  is  the  fraction  of  all  complex  errors  of  a  given  type 
that  would  not  be  equivalent  or  eliminated  by  the  test  data 
provided,  and  k  is  the  number  of  complex  errors  in  the 
sample  that  are  not  equivalent  or  eliminated. 

Let  pO  be  the  value  (found  by  iteration)  such  that 

k-1 

5“  P  (i)  *  0.975 

4-  p0 

i»0 


k-1  k-l 

P(p0<p)  -  p(  T.  P  (i)  >  ZIP  CD  ) 

i**0  pO  i»0  p 


Then 
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ku 

-22  P  (i) 

i»0  p 

Where  ku  is  the  largest  integer  such  that 
ku-1 

22  P  (i)  <  0.975 
i=0  p 


So  P(pO  <  p)  £  0.975.  By  an  analogous  argument,  P(pl  >,  p)  > 
0.975.  Our  95%  confidence  interval  is  thus  [p0,pl]. 


141 


PROGRAM  1 


1  IDENTIFICATION  DIVISION. 

2  PROGRAM-ID.  POQAACA . 

3  AUTHOR.  CPT  R  W  MORCHEAD. 

4  INSTALLATION.  HQS  USACSC. 

5  DATE-WRITTEN.  OCT  1973. 

6  REMARKS. 

7  THIS  PROGRAM  PRINTS  OUT  A  LIST  OP  CHANGES  IN  THE  ETP. 


8 

ALL  ETF  CHANGES  WERE  PROCESSED  PRIOR  TO 

THIS  PROGRAM.  THE 

9 

OLD  ETF  AND  THE  NEW  ETF  ARE  THE  INPUTS. 

BUT  THERE  IS  NO 

10 

FURTHER  PROCESSING  OP  THE  ETP  HERE. 

THE  ONLY  OUTPUT  IS  A 

11 

LISTING  OP  THE  ADDS.  CHANGES,  AND  DELETES.  THIS  PROCRAM  12 

12 

FOR  HQ  USE  ONLY  AND  HAS  N0  APPLICATION  IN  THE  FIELD. 

14 

MODIFIED  FOR  TESTING  UNDER  CPMS  BY 

ALLEN  ACREE 

15 

JULY,  1979. 

16 

ENVIRONMENT  DIVISION. 

17 

CONFIGURATION  SECTION. 

18 

SOURCE-COMPUTER.  PRIME. 

19 

OBJECT-COMPUTER.  PRIME. 

20 

INPUT-OUTPUT  SECTION. 

21 

FILE -CONTROL. 

22 

SELECT  OLD-ETF  ASSIGN  INPUT4 .  • 

23 

SELECT  NEW-ETF  ASSIGN  INPUT8. 

24 

SELECT  PRNTR  ASSIGN  TO  OUTPUT9. 

25 

DATA  DIVISION. 

26 

FILE  SECTION. 

27 

FD 

OLD-ETF 

28 

RECORD  CONTAINS  80  CHARACTERS 

29 

LABEL  RECORDS  ARE  STANDARD 

30 

DATA  RECORO  IS  OLD-REC. 

31 

01 

OLD-REC. 

32 

03  FILLER 

PIC 

X. 

33 

03  OLD-KEY 

PIC 

X  ( 12)  . 

34 

03  FILLER 

PIC 

XC67). 

35 

FD 

NEW-ETF 

36 

RECORD  CONTAINS  80  CHARACTERS 

37 

LABEL  RECORDS  ARE  STANDARD 

38 

DATA  RECORD  IS  NEW-REC. 

39 

01 

NEW-REC. 

40 

03  FILLER 

PIC 

X. 

41 

03  NEW-KEY 

PIC 

X  ( 1  2)  . 

42 

03  FILLER 

PIC 

XJ67) . 

43 

PD 

PRNTR 

44 

RECORD  CONTAINS  40  CHARACTERS 

45 

LABEL  RECORDS  ARE  OMITTED 

46 

DATA  RECORD  IS  PRNT-LINE. 

47 

01 

PRNT-LINE 

PIC 

X(40). 

48 

WORKING-STORAGE  SECTION. 

49 

01 

PRNT-WORK-AREA. 

50 

03  LINE1 

PIC 

X(30>. 

SI 

03  LINE2 

PIC 

X  (30)  . 

52 

03  LINE3 

PIC 

X(20) • 

53 

01 

PR NT-OUT -OLD. 

54 

03  WS-LN-1 . 

55 

05  FILLER 

PIC 

X  VALUE  SPACE. 

56 

05  FILLER 

PIC 

XXXX  VALUE  '0  * . 

57 

05  LN1 

PIC 

XOO). 

58 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

59 

03  WS-LN-2. 

60 

05  FILLER 

PIC 

X  VALUE  SPACE. 

61 

05  FILLER 

PIC 

XXXX  VALUE  'L  ' . 
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62 

05 

LN2 

PIC 

X/30). 

63 

05 

FILLER 

PIC 

XXX  VALUE  SPACES. 

64 

03 

WS- 

LN-3. 

65 

05 

FILLER 

PIC 

X  VALUE  SPACE. 

66 

05 

FILLER 

PIC 

XXXX  VALUE  *D  '. 

67 

05 

LN3 

PIC 

X(20) . 

68 

05 

FILLER 

PIC 

XXX  VALUE  SPACE. 

69 

01  PRNT-N  EW-OUT . 

70 

03 

NEW 

-LN-1. 

71 

05 

FILLER 

PIC 

XXXXX  VALUE  '  N  • . 

72 

05 

N-LN) 

PIC 

X (30)  . 

73 

05 

FILLER 

PIC 

XXX  VALUE  SPACE. 

74 

03 

NEW 

-LN-2. 

75 

05 

FILLER 

PIC 

XXXXX  VALUE  '  E  '. 

76 

05 

N-LN  2 

PIC 

X (30)  . 

77 

05 

FILLER 

PIC 

XXX  VALUE  SPACES. 

78 

03 

NEW 

-LN-3. 

79 

05 

FILLER 

PIC 

XXXXX  VALUE  *  W  •  . 

80 

05 

N-LN  3 

PIC 

X (20)  . 

81 

05 

FILLER 

PIC 

XXX  VALUE  SPACES. 

82  PROCEDURE  DIVISION. 

83  OlOO-OPENS. 

84  OPEN  INPUT  OLD-ETF  NEW-ETF. 

85  OPEN  OUTPUT  PRNTR. 

06  OllO-OLD-READ. 

87  READ  OLD-ETF  AT  END  CO  TO  0160-OLD-EOF. 

83  01 20 -NEW-READ. 

09  READ  NEW-ETF  AT  END  GO  TO  0170-NEW-EOF. 

90  01 30-COMPARES. 

91  IF  OLD-KEY  -  NEW-KEY 

92  NEXT  SENTENCE 

93  ELSE  GO  TO  0140-CK-ADD-DEL. 

94  IF  OLD-REC  -  NEW-REC 

95  GO  TO  OUO-OLD-READ. 

96  MOVE  OLD-REC  TO  PRNT-WORK-AREA. 

97  PERFORM  0210-OLD-WRT  THRU  02J0-EXIT. 

98  MOVE  NEW-REC  TO  PRNT-WORK-AREA. 

99  PERFORM  0200-NW- WRT  THRU  0200-EXIT. 

100  GO  TO  0110 -OLD-READ . 

101  0140-CK-ADD-DEL. 

102  IF  OLD-KEY  >  NEW-KEY 

103  MOVE  NEW-REC  TO  PRNT-WORK-AREA 

104  PERFORM  0200-NW-WRT  THRU  0200-EXIT 

105  GO  TO  0120-NEW-READ 

106  ELSE  GO  TO  0150-CX-ADD-DEL. 

107  0150-CX-ADD-DEL. 

100  MOVE  OLD-REC  TO  PRNT-WORK-AREA. 

109  PERFORM  0210-OLD-WRT  THRU  0210-EXXT. 

110  READ  OLD-ETF  AT  END 

111  MOVE  NEW-REC  TO  PRNT-WORK-AREA 

112  PERFORM  0200-NW-WRT  THRU  0200-EXIT 

113  GO  TO  0160-OLD-EOF. 

114  GO  TO  01 30-C0MPARES. 

115  0160-OLD-EOF. 

116  READ  NEW-ETF  AT  END  GO  TO  0180-EOJ. 

117  MOVE  NEW-REC  TO  PRNT-WORK-AREA. 

110  PERFORM  0200-NW-WRT  THRU  0200-EXIT. 

U9  GO  TO  0160-OLD-EOF. 

120  0170-NEW-EOF. 

121  MOVE  OLD-REC  TO  PRNT-WORK-AREA. 

122  PERFORM  0210-OLD-WRT  THRU  0210-EXIT. 

123  READ  OLD-ETF  AT  END  GO  TO  O10O-EOJ. 

124  GO  TO  0170-NEW-EOF. 

125  O10O-EOJ. 
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126  CLOSE  OLD-ETP  NEW-ETP  PRNTR. 

127  STOP  RUM. 

128  0200-NW-WRT. 

129  MOVE  LXNE1  TO  N-LM1. 

130  MOVE  LINE2  TO  N-LM2. 

131  MOVE  LIMES  TO  N-LN3. 

132  WRITE  PRMT-LIME  PROM  MEW-LM-1  AFTER  ADVANCING  2. 

133  WRITE  PRNT-LINE  PROM  NEW-LN-2  APTER  ADVANCING  1. 

134  WRITE  PRNT-LINE  PROM  MEW-LN-3  APTER  ADVANCING  1. 

135  0200-EXIT. 

136  EXIT. 

137  0210-0LD-WRT. 

138  MOVE  LINE1  TO  LM1. 

139  MOVE  LIME2  TO  LN2. 

140  MOVE  LINES  TO  LN3. 

141  WRITE  PRNT-LINE  PROM  WS-LM-1  APTER  ADVANCING  2. 

142  WRITE  PRNT-LINE  PROM  WS-LM-2  APTER  ADVANCING  1. 

143  WRITE  PRNT-LINE  PROM  WS-LN-3  APTER  ADVANCING  1. 

144  0210-EXIT. 

145  EXIT. 

146 
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PROGRAM  2 


1  IDENTIFICATION  DIVISION. 

2  PROGRAM- ID. 

3  PROG-1 . 

4  AUTHOR. 

5  JAMES  L.  BINGHAM. 

6  DATE-WRITTEN. 

7  APRIL  14.  1979. 

8 

9  ENVIRONMENT  DIVISION. 

10  CONFIGURATION  SECTION. 

11  SOURCE-COMPUTER.  PRIME. 

12  OBJECT -COMPUTER.  PRIME. 

13  INPUT-OUTPUT  SECTION. 

t i  PTT 

15  SELECT  IN-TRANSACTION  ASSIGN  TO  INPUTO. 

16  SELECT  OUTPUT-PAYMENT  ASSIGN  TO  OUTPUTO. 

17 

18  DATA  DIVISION. 

19  FILE  SECTION. 

20 


21 

FD 

IN-TRANSACTION 

22 

RECORD  CONTAINS  18  CHARACTERS. 

23 

LABEL  RECORDS  ARE  OMITTED. 

24 

DATA  RECORD  IS  TRANSACTION-RECORD. 

25 

01 

TRANSACTION-RECORD. 

26 

05  ACCT-NUM 

PIC 

9(8)  . 

27 

05  BILLED-AHT 

PIC 

9  (5) V99. 

28 

05  PERCENTAGE 

PIC 

V99. 

29 

05  ACCT-CLASS 

PIC 

X. 

30 

31 

FD 

OUTPUT-PAYMENT 

32 

RECORD  CONTAINS  55  CHARACTERS, 

33 

LABEL  RECORDS  ARE  OMITTED, 

34 

DATA  RECORO  IS  OUTPUT-RECORD. 

35 

01 

OUTPUT-RECORD 

PIC  X(55) . 

36 

37 

WORKING-STORAGE  SECTION. 

38 

39 

01 

W-TOTA  LS- OUTPUT- R  ECORD. 

40 

05  FILLER 

PIC 

X(4)  VALUE  SPACES 

41 

OS  NAME-OF-CLASS 

PIC 

X (34)  . 

42 

05  TOTAL-CLASS- PAY 

PIC 

$$$$$$9.99. 

43 

05  FILLER 

PIC 

X(4)  VALUE  SPACES 

44 

45 

01 

W-OUTPUT-RECORD. 

46 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

47 

05  W-ACCT-NUM 

PIC 

9(8)  . 

48 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

49 

05  W-BILLED-AMT 

PIC 

9(5) .99. 

50 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

51 

05  W-PERCENTACE 

PIC 

.99. 

52 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

S3 

05  W-ACCT-C  LASS 

PIC 

X. 

54 

05  FILLER 

PIC 

XXX  VALUE  SPACES. 

55 

05  W- PAYMENT 

PIC 

$$$$89.99. 

56 

57 

01 

TEMPORARY-ITEMS. 

58 

05  TOTAL-A-PAY 

PIC 

9(6) V99. 

59 

05  TOTAL-X-PAY 

PIC 

9(6)V99. 

60 

05  TOTAL-N-PAY 

pie 

9(6)V99. 

61 

05  TOTAL-T-PAY 

PIC 

9 (6)V99. 

(  ■ 


■  4 
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OS  TOTAL- 2 -PAY 
05  PAY -AMT- A 
OS  PAY-AMT-X 
05  PAY-AMT-M 
05  PAY-AMT-T 
OS  PAY-AMT-Z 

ERROR-MESSAGE. 

OS  INVALID-DATA-RECORD 


PXC  9(6)V99. 
PXC  9 (S)V99. 
PXC  9(S)V99. 
PXC  9(S)V99. 
PXC  9(S)V99. 
PXC  9 (S)V99. 


VALUE  ‘INVALID  DATA  ON  THIS  CARD*. 
01  FLAG-VALUE. 

OS  NOR  E-DATA-R EMA XNS  1 

•  88  NO-MORE-DATA-R EMA  XNS 


PXC  X(S0) 


PXC  X  VALUE  'Y* , 
VALUE  ‘N* . 


PROCEDURE  DIVISION. 

PROCESS-TRANSACTION. 

OPEN  INPUT  IN-TRANSACTXON 

OUTPUT  OUTPUT-PAYMENT. 

MOVE  ZEROES  TO  TOTAL-A-PAY,  TOTAL-X-PAY,  TOTAL-M-PAY, 
TOTAL-T-PAY,  TOTAL-Z-PAY. 

READ  IN-TRANSACTXON 

AT  END  MOVE  *N‘  TO  MORE-DATA-REMAINS. 

PERFORM  CHECK-DATA  UNTIL  MORE-DATA-REMAINS  -  'N1. 
PERFORM  WRITE-OUTPUT-TOTALS. 

CLOSE  IN-TRANSACTION 
OUTPUT-PAYMENT. 

STOP  RUN. 

CHECK-DATA. 

IF  ACCT-NUM  IS  NUMERIC 
AMD  B I LLED-AMT  IS  NUMERIC 
AND  PERCENTAGE  IS  NUMERIC 
AND  (ACCT-CLASS  -  ‘A*  OR 
ACCT-C LASS  •  *X‘  OR 
ACCT-CLASS  -  *M‘  OR 
ACCT-CLASS  -  *T‘  OR 
ACCT-CLASS  -  'Z‘> 

PERFORM  PROCESS-ONE-TRANSACTION 
ELSE 

WRITE  OUTPUT-RECORD  FROM  ERROR-MESSAGE. 

READ  IN-TRANSACTION 

AT  END  MOVE  'N‘  TO  MORE-DATA-REMAINS. 

PROCESS-ONE-TRANSACTION . 

MOVE  ACCT-NUM  TO  W-ACCT-NUM. 

MOVE  BILLED-AMT  TO  W-BXLLED-AMT. 

MOVE  PERCENTAGE  TO  W-PERCENTAGE. 

MOVE  ACCT-CLASS  TO  W-ACCT-CLASS. 

IF  ACCT-CLASS  -  'A*  OR  ACCT-CLASS  •  'X' 

COMPUTE  PERCENTAGE  -  1.00  -  PERCENTAGE 
IF  ACCT-CLASS  •  ‘A‘ 

MULTIPLY  BILLED-AMT  BY  PERCENTAGE 
GIVING  PAY-AMT-A  ROUNDED 
ADD  PAY-AMT-A  TO  TOTAL-A-PAY 
MOVE  PAY-AMT-A  TO  W-PAYMENT 

ELSE 

MULTIPLY  BILLED-AMT  BY  PERCENTAGE 
GIVING  PAY-AMT-X  ROUNDED 
ADD  PAY-AMT-X  TO  TOTAL-X-PAY 
MOVE  PAY-AMT-X  TO  W-PAYMENT. 


IF  ACCT-CLASS  •  ‘M* 


126  MULTIPLY  BILLED -AMT  BY  PERCENTAGE 

127  GIVING  PAY-AMT-M  ROUNDED 

128  ADD  PAY-AMT-M  TO  TOTAL-M-PAY 

129  MOVE  PAY-AMT-M  TO  W-PAYMENT. 

130 

131  IP  ACCT-CLASS  •  'T* 

132  MOVE  BILLSD-AMT  TO  PAY-AMT-T 

133  ADD  PAY-AMT-T  TO  TOTAL-T-PAY 

134  MOVE  PAY-AMT-T  TO  W- PAYMENT. 

135 

336  IP  ACCT-CLASS  -  'Z' 

137  MOVE  BILLED-AMT  TO  PAY-AMT-Z 

138  ADD  PAY-AMT-2  TO  TOTAL-Z-PAY 

139  MOVE  PAY-AMT-Z  TO  W-PAYNENT. 

140 

141  WRITE  OUTPUT-RECORD  PROM  W-OUTPUT-RECORD. 

142 

143  '  WRITE-OUTPUT-TOTA  LS . 

144  MOVE  TOTAL-A-PAY  TO  TOTAL-CLASS-PAY. 

145  MOVE  *  TOTAL  AMOUNT  POR  CLASS  A:  »  TO  NAME-OP-CLASS. 

146  WRITE  OUTPUT-RECORD  FROM  W-TOTALS-OUTPUT-RECORD. 

147 

148  MOVE  TOTAL-X-PAY  TO  TOTAL-CLASS-PAY. 

149  MOVE  '  TOTAL  AMOUNT  POR  CLASS  Xt  'TO  NAHE-OP-CLASS. 

150  WRITE  OUTPUT-RECORD  PROM  W-TOTALS-OUTPUT-RECORD. 

151 

152  MOVE  TOTAL-M-PAY  TO  TOTAL-CLASS-PAY. 

153  MOVE  ’  TOTAL  AMOUNT  POR  CLASS  Ms  1  TO  NAHE-OP-CLASS. 

154  WRITE  OUTPUT-RECORD  PROM  W-TOTALS-OUTPUT-RECORD. 

155 

156  MOVE  TOTAL-T-PAY  TO  TOTAL-CLASS-PAY. 

157  MOVE  •  TOTAL  AMOUNT  FOR  CLASS  Ts  •  TO  NAME-OP-CLASS. 

158  WRITE  OUTPUT-RECORD  FROM  W-TOTALS-OUTPUT-RECORD. 

159 

160  MOVE  TOTAL-Z-PAY  TO  TOTAL-CUSS-PAY. 

161  MOVE  '  TOTAL  AMOUNT  FOR  CUSS  Zs  'TO  NAME-OP-CUSS. 

162  WRITE  OUTPUT-RECORD  FROM  W-TOTALS-OUTPUT-RECORD. 

163 


PROGRAM  3 


1  IDENTIFICATION  DIVISION. 

2  PROCRAM-ID.  SAMPLE-4. 

3  REMARKS.  ADAPTED  PROM  YOUR DAM,  ET  At.  *  LEARNING  TO  PROCRAM 

4  IN  STRUCTURED  COBOL.* 

5  ENVIRONMENT  DIVISION. 

6  CONFIGURATION  SECTION. 

7  SOURCE-COMPUTER.  PRIME. 

0  OBJECT-COMPUTER.  PRIME. 

9  INPUT- OUTPUT  SECTION. 

10  PILE-CONTROL. 

11  SELECT  APPLICATION-CARDS-PILE  ASSIGN  TO  INPUTO. 

12  SELECT  PROPILE-LISTING  ASSIGN  TO  OUTPUTO. 

13 

14  .  DATA  DIVISION. 

15  PILE  SECTION. 

16 

17  PO  APPLICATION-CARDS-PILE 

18  RECORD  CONTAINS  80  CHARACTERS 

19  LABEL  RECORDS  ARE  OMITTED 

20  DATA  RECORD  IS  NAME-AODRESS-AND-PRONE-IM. 


21 

01 

NAME-ADDRESS- AND-PHONE- IN . 

22 

05 

NAME-IN 

PIC 

X (20)  . 

23 

05 

ADDRESS-IN 

PIC 

X(40) . 

2< 

05 

PHONE-IN 

PIC 

XU1)  . 

25 

05 

FILLER 

PIC 

X  <  3 )  . 

26 

05 

ACCT-NUH-IN1 

PIC 

9(6)  . 

27 

28 

PD 

PROFILE-LISTING 

29 

RECORD  CONTAINS  132  CHARACTERS 

30 

LABEL  RECORDS  ARE  OMITTED 

31 

OATA  RECORD  IS  PRINT-LINE-OUT. 

32 

01 

PRINT-LINE-OUT 

PIC 

X(132) 

33 

34 

WORKING-STORAGE  SECTION. 

35 

01 

COMMON-WS. 

36 

05 

CARDS- LEFT 

PIC 

X(3)  . 

37 

01 

CREDIT-INFORMATION-IN. 

38 

05 

CARD-TYPE- IN 

PIC 

X. 

39 

05 

ACCT-NUM-IN2 

PIC 

9(5)  . 

40 

05 

FILLER 

PIC 

X. 

41 

05 

CREDIT-INFO- IN 

PIC 

X  (22)  . 

42 

05 

FILLER 

PIC 

X(SO|. 

43 

01 

APPL1CATIOM-DATA-WSB1. 

44 

05 

NAME-AND-ADDRESS-WS . 

45 

10  NAME-WS 

PIC 

X(20) . 

46 

10  ADDRE8S-WS. 

47 

15  STREET -WS 

PIC 

X(20)  . 

48 

15  CITY-WS 

PIC 

X(13) . 

49 

15  STATE-WS 

PIC 

XX. 

50 

15  SIP-MS 

PIC 

X(S). 

51 

05 

PHONE-WS. 

52 

10  AREA-CODC-WS 

PIC 

9(3). 

53 

10  NUMBR-MS 

PIC 

X(8)  . 

54 

05 

FILLER 

PIC 

X(3)  • 

55 

05 

ACCT-NUM-WS 

PIC 

9(6)  . 

56 

05 

CREDIT- INFO-MS. 

57 

10  SEX-MS 

PIC 

X. 

58 

10  FILLER 

PIC 

X. 

59 

10  MARITAL-STATUS-MS 

PIC 

X. 

60 

10  FILLER 

PIC 

X. 

61 

10  NUMBER-DEPENS-MS 

PIC 

X. 
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62 

10  FILLER 

PIC 

X. 

63 

10  INCONE-HUNDREDS-MS 

PIC 

9(3)  . 

64 

10  FILLER 

PIC 

X. 

65 

10  YEARS-EMPLOYED-WS 

PIC 

99. 

46 

10  FILLER 

PIC 

X. 

67 

10  OWN-OR-RENT-WS 

PIC 

X. 

66 

10  FILLER 

PIC 

X. 

69 

10  NORTGAGE-OR-RENTAL-WS 

PIC 

9(3)  . 

70 

10  FILLER 

PIC 

X. 

71 

10  OTHER-PAY* ENTS -WS 

PIC 

9(3). 

72 

01 

DISCR-INCONE-CALC-FIELDS-WSC8. 

73 

OS 

ANNUAL- I NCOME-WS 

PIC 

9(5) . 

74 

05 

ANNUAL-TAX-WS 

PIC 

9(5)  . 

75 

05 

TAX-RATE-WS 

PIC 

9V99  VALUE  0.25. 

76 

05 

MONTHS- IN- YEAR 

PIC 

99  VALUE  12. 

77 

OS 

MONTHLY -NET-INCONB-WS 

PIC 

9(4)  . 

78 

05 

MONTH  LY-P A  YM  ENTS-W  S 

PIC 

9(4)  . 

79 

05 

DISCR-INCOME-WS 

PIC 

S9 (3)  . 

60 

61 

01 

LINE- 1 -MSB 3 • 

82 

05 

FILLER 

PIC 

X(5)  VALUE  SPACES. 

03 

05 

NAME-L1 

PIC 

X(20)  . 

64 

05 

FILLER 

PIC 

X(ll) 

85 

VALUE  '  PHONE  (‘ 

• 

66 

05 

AREA-C0DE-L1 

PIC 

9(3). 

87 

05 

FILLER 

PIC 

XX  VALUE  ‘ )  ‘ . 

80 

05 

NUMBR-L1 

PIC 

X(8). 

69 

05 

FILLER 

PIC 

X  (3)  VALUE  SPACES. 

90 

05 

SEX-L1 

PIC 

X(6)  . 

91 

05 

FILLER 

PIC 

X (9)  VALUE  SPACES. 

92 

05 

FILLER 

PIC 

X(14) 

93 

VALUE  ‘INCOME 

s* . 

94 

05 

I NCOM  E-HUNDREDS- L 1 

PIC 

9(3)  . 

95 

05 

FILLER 

PIC 

X  (28) 

96 

VALUE  *00  PER  YEAR; 

IN  THIS  EMPLOY  *. 

97 

05 

YEARS-EMPL0YE0-L1 . 

98 

10  YEARS-L1 

PIC 

XX. 

99 

10  DESCN-L1 

PIC 

X (16)  . 

100 

01 

LINE-2-WS83. 

101 

05 

FILLER 

PIC 

X(5)  VALUE  SPACES. 

102 

05 

STREET-L2 

PIC 

X  (20)  . 

103 

05 

FILLER 

PIC 

X(27)  VALUE  SPACES. 

104 

05 

MARITAL-STATUS-12 

PIC 

X (8)  . 

105 

05 

FILLER 

PIC 

X(7)  VALUE  SPACES. 

106 

05 

OUTGO-DESCN 

PIC 

X  (16)  . 

107 

05 

MORTGAGE-OR-RENTAL-L2 

PIC  9(3)  . 

108 

05 

FILLER 

PIC 

X(ll) 

109 

VALUE  *  PER  MTU  *  . 

110 

05 

FILLER 

PIC 

X(22) 

111 

VALUE  ‘DISCRETIONARY  INCOME  S*. 

112 

05 

DISCR-INCOME-L2 

PIC 

9(3)  . 

113 

05 

FILLER 

PIC 

X(9> 

114 

VALUE  ‘  PER  NTH  •. 

115 

01 

LINE-3-WSB3. 

114 

OS 

FILLER 

PIC 

X(5)  VALUE  SPACES. 

117 

05 

CITY-L3 

PIC 

X(13) . 

118 

05 

FILLER 

PIC 

X  VALUE  SPACE. 

119 

05 

STATE-L3 

PIC 

XX. 

120 

05 

FILLER 

PIC 

X  VALUE  SPACE. 

121 

OS 

2IP-L3 

PIC 

X(S)  . 

122 

05 

FILLER 

PIC 

X(7)  VALUE  ‘  A/Ct  *. 

123 

OS 

ACCT-NUM-L3 

PIC 

9(6) . 

124 

05 

FILLER 

PIC 

X(12)  VALUE  SPACES. 

125 

OS 

NUMBER-DEPEN8-L3 

PIC 

9. 
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126  OS  FILLER 

127  VALUE  •  DEPENDENTS 

128  05  FILLER 

129  VALUE  'OTHER  PAYMENTS  8*. 

130  05  OTHER-PA YMEMTS-L3 

131 

132  PROCEDURE  DIVISION. 

133  AO -MAIN-BODY. 

134  PERFORM  Al-INITIALIZATION. 

135  PERFORM  A2 -PRINT-PROFILES 

136  UNTIL  CARDS-LEFT  -  'NO  ' . 

137  PERFORM  A3-END-OF-JOB. 

138  STOP  RUN. 

139 

140  Al-INITIALIZATION. 


PIC  X| 14) 
PIC  X(16) 
PIC  9(3). 


141  OPEN  INPUT  APPLICATI ON-CARDS-F I LE 

142  OUTPUT  PROFILE-LISTING. 

143  USELESS  INITIALIZATIONS  HAVE  BEEN  COMMENTED  OUT 

144  •**  MOVE  ZEROES  TO  ANNUAL- INCONE-WS. 

145  MOVE  ZEROES  TO  ANNUAL-TAX-WS. 

146  "*  MOVE  ZEROES  TO  MONTH LY-N ET- 1 NCOM  E-WS . 

147  ***  MOVE  ZEROES  TO  MONTHLY-PAYMENTS-WS. 

148  •••  MOVE  ZEROES  TO  DISCR-INCOME-WS. 

149  MOVE  'YES'  TO  CARDS-LEFT. 

150  READ  APPLICATION-CARDS-FILE 

151  AT  END  MOVE  'NO  •  TO  CARDS-LEFT. 

152  *  THE  FIRST  CARD  OF  A  PAIR  IS  NOW  IN  THE  BUFFER. 

153 

154  A  2-PRINT- PROFILES. 

155  PERFORM  B 1 -G ET- A-PA IR-OF-C ARDS- 1 NTO-WS . 

156  PERFORM  82-CALC-DISCRSTNRY-INCOME. 

157  PERFORM  B3-ASSEMBLE-PRINT-LINES. 

158  PERFORM  B4 -WRITE-PROF I LE . 

159 

160  A3-END-OF-JOB. 

161  CLOSE  APPLICATION-CARDS-FILE 

162  PROFILE-LISTING. 

163 

164  B 1 -GET-A-PA IR-OF-CARDS- INTO-WS . 

165  MOVE  NAME-IN  TO  NAME-WS. 

166  MOVE  ADDRESS-IN  TO  ADDRESS-WS. 

167  MOVE  PHONE-IN  TO  PHONE-WS. 

168  MOVE  ACCT-N UM- 1 N 1  TO  ACCT-NUM-WS. 

169  READ  APPLICATION-CARDS-FILE  INTO  CREDIT-INFORMATION-IN 

170  **•  AT  END  MOVE  'NO  '  TO  CARDS-LEFT. 

171  AT  END  MOVE  '  •••  MISSING  SECOND  CARD  OF  PAIR  *••• 

172  TO  PRINT-LINE-OUT 

173  WRITE  PRINT-LINE-OUT  AFTER  ADVANCING  2  LINES 

174  PERFORM  A3-EMD-0P-J0B 

175  STOP  RUN. 

176  •  THE  SECOND  CARD  OF  THE  PAIR  IS  NOW  IN  THE  SUFFER. 

177  MOVE  CREDIT-INFO-IN  TO  CREDIT-INFO-WS 

178  READ  APPLICATION-CARDS-FILE 

179  AT  END  MOVE  'MO  *  TO  CARDS-LEFT. 

180  •  THE  FIRST  CARD  OF  THE  NEXT  PAIR  IS  NOW  IN  THE  BUFFER. 

181 

182  B2-CALC-DISCRETNRY-INC0HE. 

183  COMPUTE  ANMUAL-INCOME-WS  •  INCOME-HUNDREDS-WS  *  100. 

184  COMPUTE  ANNUAL-TAX-WS  •  AMNUAL-1 NCOM E-WS  •  TAX-RATE-WS. 

185  COMPUTE  MONTHLY-NET-INCOME-WS  ROUNDED 

186  •  (ANNUAL- I NCOM E-WS  -  ANNUAL-TAX-WS)  /  MONTHS- IN- YEAR. 

187  COMPUTE  MONTHLY-PAEMENTS-WS  •  NORTCACE-OR-REMTAL-WS 

188  ♦  OTHER-  PAYMEMTS-WS. 

189  COMPUTE  DISCR-INCOME-WS  •  MONTHLY-NET-INCOME-WS 
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190 

191 

192 

193 

194 

195 

196 

197 
199 

199 

200 
201 
202 

203 

204 

205 

206 

207 

208 

209 

210 
211 
212 

213 

214 

215 

216 

217 

218 

219 

220 
221 
222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 
23$ 

236 

237 
239 


-  MOMTHLY-PAYMENTS-WS 
ON  SIZE  ERROR  ROVE  999  TO  DISCR-INCONE-WS. 

•  DISCRETIONARY  INCOMES  OVER  $999  PER  MONTH  ARE  SET  AT  $999. 

B3-ASSEMBLE- PRINT-LINES. 

MOVE  NAHE-WS  TO  NAME-L1. 

MOVE  STREBT-WS  TO  STREET-L2. 

MOVE  CITY-WS  TO  CITY-L3. 

MOVE  STATE-W3  TO  STATE- L 3. 

ROVE  ZIP-WS  TO  ZIP-L3. 

MOVE  AREA-CODE-WS  TO  AREA-COOE-Ll. 

MOVE  NUMBR-WS  TO  NUMBR-L1. 

MOVE  ACCT-NUM-MS  TO  ACCT-NUM-L3. 

IP  SEX-WS  -  'M*  MOVE  'RALE  *  TO  SEX -LI. 

IP  SEX-WS  •  'F*  MOVE  ‘FEMALE*  TO  SEX-L1. 

IP  MARITAL-STATUS-WS  ■  'S'  MOVE  'SINGLE  ' 

TO  MARITAL-STATUS-L2. 

IP  MARITAL-STATUS-WS  -  'M*  MOVE  'MARRIED  • 

TO  MARITAL-STATUS-L2. 

IP  MARITAL-STATUS-WS  -  'D*  MOVE  'DIVORCED* 

TO  MARITAL-STATUS-L2. 

IP  MARITAL-STATUS-WS  •  'W*  MOVE  'WIDOWED  * 

TO  MARITAL-STATUS-L2. 

MOVE  NUMBER-DEPEMS-WS  TO  NUMBER-DEPENS-L3. 

MOVE  INCOHE-HUNDREOS-WS  TO  INCOME-HUNDREDS-L1. 

IP  YEARS-EMPLOYED-WS  IS  EQUAL  TO  0 

MOVE  'LESS  THAN  1  YEAR'  TO  YEARS-EMPLOYED-L1 

ELSE 

MOVE  YEARS-EMPLOYED-WS  TO  YEARS-L1 
MOVE  '  YEARS  '  TO  DESCM-L1. 

IP  OWM-OR-R EMT-WS  -  *0*  MOVE  'MORTGAGE:  $’ 

TO  OUTCO-OESCM . 

IP  OWN-OR-REMT-WS  -  'R*  MOVE  'RENTAL:  $' 

TO  OUTGO-OESCN. 

MOVE  MORTGAGE-OR-RENTAL-WS  TO  MORTGAGE-OR-RENTAL-L2^ 

MOVE  OTHER- PA YMENTS-WS  TO  OTHER-PAYMENTS-L3. 

MOVE  DISCR-INCOME-WS  TO  DISCR-INC0ME-L2. 

B4 -WRITE- PROP I LE . 

•**  MOVE  SPACES  TO  PRINT-LINE-OUT. 

WRITE  PRINT-LINE-OUT  PROM  LINE-1-WSB3 
AFTER  ADVANCING  4  LINES. 

MOVE  SPACES  TO  PRINT-LINE-OUT. 

WRITE  PRINT-LINE-OUT  PROM  LINE-2-WSB3 
AFTER  ADVANCING  1  LINES. 

MOVE  SPACES  TO  PRINT-LINE-OUT. 

WRITE  PRINT-LINE-OUT  PROM  LINE-3-WSB3 
AFTER  ADVANCING  1  LINES. 
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PROGRAM  4 


1  identification  division. 

2  PROGRAM-ID.  SRHFREP. 

3  AUTHOR.  R  A  OVERSEER. 

4  REMARKS.  THIS  PROGRAM  IS  USED  TO  PRODUCE  THE  STATUS  REPORTS 

5  BY  DEPARTMENT.  TOR  ALL  OP  THE  STUDENTS  RECORDED  IN 

6  THE  SRMP. 

7 

8  ADAPTED  TO  THE  COBOL  MUTATION  SYSTEM  BY  ALLEN  ACRES. 

9 

10  ERRORS  DISCOVERED: 

11 

12  (1)  ERRORS  IN  THE  INPUT  FILE  SETUP.  CHECKED  POR 

13  IN  THE  PROGRAM,  CAUSE  REFERENCES  TO  UNDEFINED 

14  DATA,  PARTICULARLY  LINE-COUNT.  CORRECTED  WITH 

15  A  VALUE  CLAUSE. 

IS  ENVIRONMENT  DIVISION. 

17  CONFIGURATION  SECTION. 

18  SOURCE-COMPUTER.  CMS. 

19  OBJECT-COMPUTER.  CMS. 

20  SPECIAL-NAMES.  C01  IS  TOP-OP-PAGE. 

21  INPUT-OUTPUT  SECTION. 

22  PILE-CONTROL. 

23  SELECT  MASTER  ASSIGN  TO  INPUTO.  ‘ 

24  SELECT  PRINT-PILE  ASSIGN  TO  OUTPUTO. 

25 

26  DATA  DIVISION. 

27  PILE  SECTION. 


28 

PD 

MASTER 

29 

RECORD  CONTAINS  141  CHARACTERS, 

30 

LABEL  RECORDS  ARE  STANDARD, 

31 

DATA  RECORD  IS  ITEM. 

32 

01 

ITEM. 

33 

02  SOC-SEC-IN. 

34 

03  SOC-SEC-IN-1 

PIC 

X(3)  . 

35 

03  SOC-SEC-IN- 2 

PIC 

X  { 2)  . 

36 

03  SOC-SEC-IN- 3 

PIC 

X<4)  . 

37 

02  NAME-IN 

PIC 

X  (5)  . 

38 

02  A DOR-IN— 1 

PIC 

X(5)  . 

39 

02  ADDR-IN-2 

PIC 

X (5)  . 

40 

02  MAJOR- IN 

PIC 

X(4). 

41 

02  STATUS- IN 

PIC 

XII)  . 

42 

02  NO-COURSES 

PIC 

99. 

43 

02  COURSE-ENTRY  OCCURS  U  TINES. 

44 

03  DEFT-OPF 

PIC 

X(2)  . 

45 

03  COURSE-NO 

PIC 

X(2)  . 

46 

03  CREDITS 

PIC 

99. 

47 

03  SEMESTER 

PIC 

X(l)  . 

48 

03  YEAR 

PIC 

XU)  . 

49 

03  GRADE 

PIC 

X(l) . 

50 

PD 

PRINT-PILE 

51 

RECORD  CONTAINS  89  CHARACTERS 

52 

LABEL  RECORD*  ARE  OMITTED 

53 

DATA  RECORD  IS  PRINT-BUPP. 

54 

01 

PRINT-BUFF 

PIC 

XC89) 

55 

56 

WORKING-STORAGE  SECTION. 

57 

77 

END-ALL 

PIC 

99. 

58 

77 

END-MARKER 

PIC 

99. 

59 

77 

P-INDEX 

PIC 

9. 

60 

77 

POINTS 

PIC 

999. 

61 

77 

CR-HRS 

PIC 

999. 

62 

77 

INCR 

63 

77 

C-INDEX 

64 

77 

PACS-NO 

65 

77 

LINE-COUNT 

66 

77 

SAVE-KEY 

67 

77 

TOT-NO-RECORDS 

68 

77 

SUB- TOT- NO 

69 

70 

01 

READER. 

71 

02 

PILLER 

72 

02 

COLLEGE 

73 

02 

DATE- IN 

74 

01 

TRAILER. 

75 

02 

PILLER 

76 

02 

NO-RECOROS 

77 

01 

PRINT-LINE. 

78 

02 

PILLER 

79 

02 

SOC-SEC-OUT. 

80 

03  SOC-SEC-Ol 

81 

03  SOC-SEC-F1 

82 

03  S0C-SEC-02 

83 

03  SOC-SEC-F2 

84 

03  S0C-SEC-03 

85 

02 

PILLER 

86 

02 

NANE-ADDR 

87 

02 

PILLER 

88 

02 

NAJOR-O 

89 

02 

PILLER 

90 

02 

STATUS-0 

91 

02 

PILLER 

92 

02 

CPA 

93 

02 

PILLER 

94 

02 

COURSE-0  OCCURS  3 

95 

03  C-DEPT 

96 

03  PILLER 

97 

03  C-NO 

98 

03  PILLER 

99 

03  CREDITS -0 

100 

03  FILLER 

101 

03  SEMESTER-0 

102 

03  DASH-0 

103 

03  YEAR-0 

104 

03  PILLER 

105 

03  GRADE-0 

106 

03  PILLER 

107 

02 

PILLER 

108 

01 

PACE-HEADER. 

109 

02 

PILLER 

110 

02 

DATE-0 

111 

02 

FILLER 

112 

02 

COLL-O 

113 

02 

PILLER 

114 

02 

FILLER 

US 

02 

PACE-0 

116 

02 

PILLER 

117 

01 

COL 

-HDR-1 . 

118 

02 

PILLER 

119 

VALUE  '  SOC  SEC 

120 

02 

PILLER 

121 

02 

PILLER 

122 

02 

FILLER 

123 

02 

FILLER 

124 

02 

PILLER 

125 

02 

FILLER 

PIC  99. 

PIC  99. 

PIC  999  VALUE  IS  1. 

PIC  99  VALUE  ZERO. 

PIC  X(4). 

PIC  9999999  VALUE  IS  0. 
PIC  9999999. 


PIC  X(14). 

PIC  X (30) . 

PIC  X(8>. 

PIC  X(49) . 

PIC  9999999. 

PIC  X(l). 

PIC  X(3) . 

PIC  X(l)  . 

PIC  X(2) . 

PIC  X(l)  . 

PIC  X(4)  . 

PIC  X (2) . 

PIC  X(5). 

pic  xu) . 

PIC  X(4) . 

PIC  XU)  . 

PIC  XU)  . 

PIC  XU)  . 

PIC  9.99. 

PIC  X(2) . 

TINES. 

PIC  X(2). 

PIC  X(l). 

PIC  X  (2)  . 

PIC  XU). 

PIC  Z9. 

PIC  X(l) . 

PIC  X(l)  . 

pic  xu> . 

PIC  X(2)  . 

PIC  X(2)  . 

PIC  X(l) . 

PIC  Xf 2) . 

PIC  X (2) . 

PIC  X(4)  VALUE  SPACES. 

PIC  X(S) . 

PIC  XU7)  VALUE  SPACES. 

PIC  X(30) . 

PIC  XU7)  VALUE  SPACES. 

PIC  XfS)  VALUE  IS  ’PACE*. 
PIC  ZZ9. 

PIC  X(5)  VALUE  SPACES. 

PIC  X(20) 

N  i  A  '. 

PIC  XUO)  VALUE  ’RAJ  ST  CPA’ 
PIC  X(9)  VALUE  SPACES. 

PIC  X(5>  VALUE  ’COURSE*. 

PIC  X(12)  VALUE  SPACES. 

PIC  X(«)  VALUE  ’COURSE*. 

PIC  XU2)  VALUE  SPACES. 
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126 

02 

FILLER 

PIC 

X<6)  VALUE  'COURSE* 

127 

02 

FILLER 

PIC 

X  <8 )  VALUE  SPACES. 

128 

01 

COL-HDR-2. 

129 

02 

FILLER 

PIC 

X(33)  VALUE  SPACES. 

130 

02 

FILLER 

PIC 

XC18) 

131 

VALUE 

•  NMBR 

CR 

S-YR 

GR 

i 

• 

132 

02 

FILLER 

PIC 

XUS) 

133 

VALUE 

'  NMBR 

CR 

S-YR 

GR 

• 

• 

134 

02 

FILLER 

PIC 

X(20) 

135 

VALUE 

*  NMBR 

CR 

S-YR 

GR 

• 

136 

01 

SUB-TOT-LINE. 

137 

02 

FILLER 

PIC 

X(4)  VALUE  SPACES. 

138 

02 

FILLER 

PIC 

X(8) 

139 

VALUE 

IS  ‘TOTAL 

•  *. 

140 

02 

SUB -TOT 

PIC 

2ZZ2ZZ9. 

141 

02 

FILLER 

PIC 

X(70)  VALUE  SPACES 

142  PROCEDURE  DIVISION. 

143  •  MAIN-PROCRAM  SECTION. 

144  START. 

145  OPEN  INPUT  MASTER  OUTPUT  PRINT-PILE. 

146  READ  MASTER  INTO  HEADER  AT  END  GO  TO  EOP. 

147  IP  SOC-SEC-IN  IS  -  SPACES  GO  TO  GOT-HEADER. 

148  MOVE  *  NO  HEADER  POUND  ON  THE  MASTER  PILE  ••••  TO  PRINT-LINE. 

149  PERFORM  PRINT 2 -ROUTINE  THRU  PRINT2-EXIT. 

150  GO  TO  CLOSE-FILES. 

151  GOT-HEADER. 

152  MOVE  COLLEGE  TO  COLL-O. 

153  MOVE  DATE- IN  TO  DATE-O. 

154  READ  MASTER  AT  END  GO  TO  EOP. 

155  IP  SOC-SEC-IN  IS  NOT  -  *999999999*  CO  TO  SAVE-DEPT-NAME. 

156  MOVE  •  NO  ITEM  RECORDS  IN  MASTER  PILE  •••*  TO  PRINT-LINE. 

157  PERFORM  PRINT2-ROUTINE  THRU  PRINT2-EXIT. 

158  CO  TO  CLOSE-PILES. 

159  SAVE-DEPT-NAME. 

160  MOVE  MAJOR-IN  TO  SAVE-XEy. 

161  •  NAME  OP  DEPARTMENT  IS  SUBTOTAL  KEY.  BREAK  OCCURS  WHENEVER 

162  •  FIELD  IS  DIFFERENT  ON  TWO  CONSECUTIVE  RECORDS. 

163  MOVE  0  TO  SUB-TOT-NO. 

164  MOVE  1  TO  PAGE-NO. 

145  •  PAGE-NO  IS  RESET  TO  1  FOR  EACH  DEPARTMENT  REPORT. 

166  MOVE  16  TO  LINE-COUNT. 

167  HOVE  SPACES  TO  PRINT-LINE. 

168 

169  ITEM-LOOP. 

170  PERFORM  ITEM-ROUTINE  THRU  ITEM-EXIT. 

171  ADD  1  TO  SUB-TOT-NO. 

172  READ  MASTER  INTO  TRAILER  AT  END  GO  TO  EOP. 

173  IP  MAJOR-IN  IS  -  SAVE-KEY  GO  TO  ITEM-LOOP. 

174 

175  DO-SUB-TOTALS. 

176  MOVE  SUB-TOT-NO  TO  SUB-TOT. 

177  WRITE  PRINT-BUPP  PROM  SUB-TOT-LINE  AFTER  ADVANCING  2  LINES. 

178  ADD  SUB-TOT-NO  TO  TOT-NO-RECORDS. 

179  IP  SOC-SEC-IN  IS  NOT  -  '999999999*  GO  TO  SAVE-DEPT-NAME. 

180  MOVE  TOT-NO-RECORDS  TO  SUB-TOT. 

181  WRITE  PRINT-BUPP  PROM  SUB-TOT-LINE 

182  AFTER  ADVANCING  TOP-OP-PAGE. 

183  IP  NO-RECORDS. IS  ■  TOT-NO-RECORDS  CO  TO  CLOSE-PILES. 

184  MOVE  •  •••  MASTER  TRAILER  VERIFICATION  HAS  FAILED  *•«' 

185  TO  PRINT-LINE. 

186  PERFORM  PRINT2-R0UTINE  THRU  PRINT2-EXIT. 

187  CLOSE-PILES. 

188  CLOSE  MASTER  PRINT-PILE. 

189  STOP  RUN. 


190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 
201 
202 

203 

204 

205 

206 

207 

208 

209 

210 
211 
212 

213 

214 

215 

216 

217 

218 

219 

220 
221 
222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 
24  3 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 


eof. 

MOVE  •  EOF  OH  MASTER  FILE  **•*•  TO  PRINT-LINE* 

PERFORM  PRINT2 -ROUTINE  THRU  PRINT2-EXIT. 

SO  TO  CLOSE-FILES. 

•  SUB-ROUTINE  SECTION. 

PRINT1-ROUTINE. 

IF  LINE-COUNT  IS  <  16  GO  TO  NORMAL-PRINT. 

PERFORM  HEADER-ROUTINE  THRU  HEADER-EXIT. 

WRITE  PRINT-BUFF  FROM  PRINT-LINE  AFTER  ADVANCING  2  LINES 
ADD  2  TO  LINE-COUNT. 

GO  TO  COMMON-POINT. 

NORMAL-PRINT. 

WRITE  PRINT-BUFF  FROM  PRINT-LINE  AFTER  ADVANCING  1  LINES 
ADD  1  TO  LINE-COUNT. 

COMMON-POINT. 

MOVE  SPACES  TO  PRINT-LINE. 

PRINT1-EXIT.  EXIT. 

PRINT2-ROUTINE. 

IF  LINE-COUNT  IS  >  14 

PERFORM  HEADER-ROUTINE  THRU  HEADER-EXIT. 

WRITE  PRINT-BUFF  FROM  PRINT-LINE  AFTER  ADVANCING  2  LINES 
ADD  2  TO  LINE-COUNT. 

MOVE  SPACES  TO  PRINT-LINE. 

PRINT2-EXIT.  EXIT. 

HEADER-ROUTINE. 

MOVE  PAGE -NO  TO  PAGE-O. 

WRITE  PRINT-BUFF  FROM  PAGE-HEADER 
AFTER  ADVANCING  TOP-OF-PAGE. 

ADD  1  TO  PAGE-NO. 

WRITE  PRINT-BUFF  FROM  COL-HDR-1  AFTER  ADVANCING  2  LINES. 
WRITE  PRINT-BUFF  FROM  COL-HDR-2  AFTER  ADVANCING  1  LINES. 
MOVE  0  TO  LINE-COUNT. 

HEADER-EXIT.  EXIT. 

ITEM-ROUTINE. 

MOVE  SOC-SEC-IN- 1  TO  SOC-SEC-Ol. 

MOVE  SOC-SEC-IN- 2  TO  S0C-SEC-02. 

MOVE  SOC-SEC-IN- 3  TO  SOC-SEC-03. 

MOVE  TO  SOC-SEC-F1. 

MOVE  TO  SOC-SEC-F2. 

MOVE  NAME-IN  TO  NAHE-ADDR. 

MOVE  MAJOR- IN  TO  MAJOR-O. 

MOVE  STATUS- IN  TO  STATUS-0 

•  CALCULATE  THE  GPA. 

MOVE  0  TO  POINTS. 

MOVE  0  TO  CR-RRS.  . 

PERFORM  GPA- ACC UM  THRU  GPA-EXIT  VARYING  C-INDEX 
FROM  1  BY  1  UNTIL  C-lNDEX  IS  >  NO-COURSES. 

IF  CR-HRS  IS  -  0  GO  TO  NO-GPA. 

DIVIDE  POINTS  BY  CR-HRS  GIVING  GPA  ROUNDED. 

•  IN  THE  FOLLOWING  THESE  INDICES  ARE  USEDi 

•  END-ALLi  THE  INDEX  OF  THE  FIRST  UNUSED  COURSE 

•  ENTRY)  THIS  MARKS  THE  END  OF  THE  COURSES 

•  TO  PRINT) 

•  END-MARKER i  WHEN  FILL-LINE  IS  CALLED  END-MARKER 

•  POINTS  AT  THE  FIRST  COURSE  ENTRY  PAST  THE 

•  LAST  ENTRY  TO  BE  PUT  INTO  THE  LINE) 

•  C-INOEXt  WHEN  FILL-LINE  IS  CALLED  C-INDEX  POINTS 

•  AT  THE  FIRST  COURSE  ENTRY  WHICH  GETS 

•  PUT  INTO  THE  PRINT-LINE)  THUS,  IF  C-INDEX 
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254  •  IS  EQUAL  TO  END-MARKER,  NO  COURSE  ENTRIES 

255  *  GET  PUT  INTO  THE  PRINT  LINE} 

256  •  P-INOEXi  INDEXES  THE  SPOT  IN  THE  PRINT-LINE 

257  *  WHERE  THE  ENTRY  POINTED  TO  BY  C-INDEX 

256  •  IS  TO  BE  MOVED;  THUS,  ITS  RANGE  IS  1  TO  3. 

259 

260  NO-GPA. 

261  MOVE  1  TO  C-INDEX. 

262  ADO  1  NO-COURSES  GIVING  END-ALL. 

263  MOVE  4  TO  END-MARKER. 

264  IP  END-ALL  IS  <  END-MARKER  MOVE  END-ALL  TO  END-MARKER. 

265  PERFORM  PILL-LINE  THRU  PILL-EXIT. 

266  PERFORM  PRINT2-ROUTINE  THRU  PRINT2-EXIT. 

267  MOVE  ADDR-IN-1  TO  NAME-ADDR. 

268  MOVE  7  TO  END-MARKER. 

269  IP  END-ALL  IS  <  END-MARKER  MOVE  END-ALL  TO  END-MARKER. 

270  PERFORM  PILL-LINE  THRU  FILL-EXIT. 

271  PERFORM  PR INTI -ROUTINE  THRU  PRINTl-EXIT. 

272  HOVE  ADOR-IN-2  TO  NAME-ADDR. 

273  MOVE  10  TO  END-MARKER. 

274  COURSE-LOOP. 

275  IF  END-ALL  IS  <  END-MARKER  MOVE  END-ALL  TO  END-MARKER. 

276  PERFORM  PILL-LINE  THRU  FILL-EXIT. 

277  PERFORM  PRINT1-ROUTINE  THRU  PRINTl-EXIT. 

278  IP  C-INDEX  •  END-ALL  GO  TO  ITEM-EXIT. 

279  ADD  3  C-INDEX  GIVING  END-MARKER. 

280  GO  TO  COURSE-LOOP. 

281  ITEM-EXIT.  EXIT. 

282  PILL-LINE. 

283  MOVE  1  TO  P-INDEX. 

284  CHECK-END. 

285  IF  C-INDEX  IS  •  END-M ARXER  GO  TO  FILL-EXIT. 

286  MOVE  DEPT-OFF  (C-INDEX)  TO  C-DEPT  (P-INDEX) . 

287  MOVE  COURSE-NO  (C-INDEX)  TO  C-NO  (P-INDEX) . 

288  MOVE  CREDITS  (C-INDEX)  TO  CREDITS-0  (P-INDEX) . 

289  MOVE  SEMESTER  (C-INDEX)  TO  SEMESTER-0  (P-INDEX) . 

290  MOVE  •-•  TO  DASH-0  (P-INDEX). 

291  MOVE  YEAR  (C-INDEX)  TO  YEAR-0  (P-INDEX). 

292  MOVE  GRADE  (C-INDEX)  TO  GRADE-0  (P-INDEX) . 

293  ADD  1  TO  C-INDEX. 

294  ADD  1  TO  P-INDEX. 

295  GO  TO  CHECK-END. 

296  FILL-EXIT.  EXIT. 

297 

298  GPA-ACCUM. 

299  IP  GRADE  (C-INDEX)  IS  NOT  •  'A*  GO  TO  NOTA. 

300  MULTIPLY  CREDITS  (C-INDEX)  BY  4  GIVING  INCH. 

301  GO  TO  COMMON-ADD. 

302  NOTA. 

303  IP  GRADE  (C-INDEX)  IS  NOT  •  'B*  GO  TO  NOTB. 

304  MULTIPLY  CREDITS  (C-INDEX)  BY  3  GIVING  INCR. 

305  CO  TO  COHMOM-ADD. 

306  NOTB. 

307  IF  GRADE  (C-INDEX)  IS  NOT  •  'C*  GO  TO  NOTC. 

308  MULTIPLY  CREDITS  (C-INDEX)  BY  2  GIVING  INCR. 

309  GO  TO  COMMON-ADD. 

310  NOTC. 

311  IF  GRADE  (C-INDEX)  IS  MOT  ■  'D'  GO  TO  MOTD. 

312  MULTIPLY  CREDITS  (C-INDEX)  BY  1  GIVING  INCR. 

313  GO  TO  COMMON-ADD. 

314  NOTD. 

315  IF  GRADE  (C-INDEX)  IS  NOT  -  'P'  GO  TO  GPA-EXIT. 

316  MOVE  0  TO  INCR. 

317  COMMON-ADD. 
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23 

24 
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27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 
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IDENTIFICATION  DIVISION. 

REPORT  CONTAINS  THE  INPUT  DATA  ALONG  WITH  THE 
CURRENT  COMMISSION  FOR  EACH  SALESMAN.  AT  THE 
END  OP  THIS  SINGLE  SPACED  REPORT  THE  FOLLOWING 
TOTALS  ARE  PRINTED:  YEAR  TO  DATE  SALES.  CUR¬ 
RENT  SALES,  CURRENT  COMMISSION. 

CURRENT  COMMISSION  IS  CALCULATED  AS  FOLLOWS: 
CURRENT-COMMISSION  •  CURRENT-SALES  • 

(  COMMISSION-RATE  ♦  VOLUME-BONUS  4  DEPARTMENT-BONUS  ) 

WITS  DEPARTMENT  BONUS  DETERMINED  AS  FOLLOWS: 


DEPT 

BONUS 

01 

0.1% 

02 

0.1% 

04 

0.7% 

05 

0.6% 

06 

0.4% 

07 

0.6% 

09 

0.4% 

OTHER 

0.0% 

WITH  VOLUME  BONUS  DETERMINED  AS  FOLLOWS: 


AVERAGE  MONTHLY  SALES  BONUS 

UNDER  S500  0.0% 

S500  TO  8999.99  0.3% 

$1000  TO  $1999.99  0.4% 

OVER  $2000  0.6% 


WITH  AVERAGE  MONTHS  SALES  DETERMINED  AS  FOLLOWS: 
AVERAGE-MONTHLY-SALES  - 

(  YEAR-TO-DATE-SALES  ♦  CURRENT-SALES  )  /  MONTHS-EMPLOYED 
PROGRAM-ID.  COMMISSION-REPORT. 

AUTHOR. 

DANIEL  CASTAGNO , ICS  3400, STUDENT  NUMBER  654, PROGRAM  1. 

REMARKS.  SLIGHTLY  MODIFIED  FOR  CMS.l  BY  A. ACRES. 

MUTATION  TESTING  UNCOVERED  THE  FOLLOWING  ERRORS  AND 
INEFFICIENCIES: 

(1)  REPORT  HEADER  WITH  PAGE  ADVANCE  WAS  NOT  PRINTED 
AFTER  FULL-PAGE  CONDITION  RAISED  BY  INVALID  DATA  RECORD 
EXTRA  PERFORM  INSERTED. 

(2)  DATA  ITEMS  DEFINED  AND  NEVER  USED  —  DELETED. 

(3)  MOVE  STATEMENT  REPEATED  —  SECOND  VERSION  DELETED. 

(4)  TWO  USELESS  INITIALIZATIONS  DELETED. 


ENVIRONMENT  DIVISION. 


CONFIGURATION  SECTION. 
SOURCE-COMPUTER. 

CYBER-74. 

OBJECT-COMPUTER. 

CYBER-74. 


SPECIAL-NAMES. 

C01  IS  TO-TOP-OP-PACE. 


INPUT-OUTPUT  SECTION 
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62 

FILE -CONTROL. 

63 

SELECT  CARD-FILE  ASSIGN  TO  INPUTO. 

64 

SELECT  PRINT-FILE  ASSIGN  TO  OUTPUTO. 

65 

66 

DATA  DIVISION. 

67 

68 

FILE  SECTION. 

69 

70 

FD 

CARD-FILE 

71 

RECORD  CONTAINS  80  CHARACTERS. 

72 

LABEL  RECORDS  ARE  OMITTED, 

73 

DATA  RECORD  IS  CARD-RECORD. 

74 

75 

01 

CARD-RECORD. 

76 

02  I -CARD-DATA. 

77 

03  1-STORE-NUMBER 

PIC 

99. 

78 

03  I-DEPARTMENT 

PIC 

XX. 

79 

03  I -SALESMAN-NUMBER 

PIC 

999. 

60 

03  I -SALESMAN-NAME 

PIC 

X  (20)  . 

81 

03  I -YEAR-TO-DATE-SALES 

PIC 

9 (5)V99. 

82 

03  I -CURRENT-SA  LES 

PIC 

9<5)V99. 

83 

03  I -COMMISSI ON-RATE 

PIC 

V99. 

84 

0?  I -MONTHS- EMPLOYED 

PIC 

99. 

85 

02  FILLER 

PIC 

X(35)  . 

86 

87 

FD 

PRINT-FILE 

88 

RECORD  CONTAINS  132  CHARACTERS 

, 

89 

LABEL  RECORDS  ARE  OMITTED, 

90 

DATA  RECORD  IS  LINE-RECORD. 

91 

92 

01 

LINE-RECORD 

PIC 

X(1 32)  . 

93 

94 

95 

WORKING-STORAGE  SECTION. 

96 

97 

77 

W-DE  PA  RTM  ENT- BONUS 

PIC 

V999. 

98 

77 

W- VOLUME-BONUS 

PIC 

V999. 

99 

77 

W-DEPARTMENT 

PIC 

XX. 

100 

77 

W-STORE-NUMBER 

PIC 

99. 

101 

77 

W-SA  LESM AN-N  UMBER 

PIC 

999. 

102 

77 

W-YEAR-TO-DATE-SALES 

PIC 

9(5)V99 

103 

77 

W -CURRENT-SALES 

PIC 

9 15)  V99. 

104 

77 

W-COMMISS ION-RATE 

PIC 

V99. 

105 

77 

W-MONTHS-EMPLOYED 

PIC 

99. 

106 

77 

W-CURRENT-COMM ISSION 

PIC 

9 (4)V99 

107 

77 

W-TOTA  L- YEAR-TO-DATE- S ALES 

PIC 

9 (9)V99 

108 

VALUE  0. 

109 

77 

W-TOTAL-CURRENT-SA  LES 

PIC 

9(8) V99 

110 

VALUE  0. 

111 

77 

W- TOTAL-CURRENT-COMMISSION 

PIC 

9(7)V99 

112 

VALUE  0. 

113 

77 

W- AVERAGE- MONTHLY- SALES 

PIC 

9(7)V99 

114 

VALUE  0. 

115 

116 

117 

•01 

XEY-TO-RECORDS. 

118 

• 

02  SALESMAN-NUN 

PIC 

999. 

119 

120 

01 

FLAGS. 

121 

02  VA  LI D-DATA-F  LAG 

PIC 

XXX 

122 

VALUE  'YES’. 

123 

02  MORE-DATA-REMAINS-FLAG 

PIC 

XXX 

124 

VALUE  ’YES’. 

125 

*  / 


I 


126 

01 

CONSTANTS • 

127 

02 

DEPT. 

128 

03  DEPT-l-OR-2 

PIC 

V999 

129 

VALUE  0.001. 

130 

03  OEPT-6-OR-9 

PIC 

V999 

131 

VALUE  0.004. 

132 

03  DEPT-5-QR-7 

PIC 

V999 

133 

VALUE  0.006. 

134 

01  DEPT-4 

PIC 

V999 

135 

VALUE  C.007. 

130 

03  QEPT-OTHER 

PIC 

V999 

137 

VALUE  0.000. 

138 

02 

VOLUMN. 

139 

03  LEVEL-1 

PIC 

V999 

140 

VALUE  0. 

141 

03  LEVEL-2 

PIC 

V999 

142 

VALUE  0.003. 

143 

03  LEVEL-3 

PIC 

V999 

144 

VALUE  0.004. 

145 

03  LEVEL-4 

PIC 

V999 

146 

VALUE  0.006. 

147 

148 

01 

COUNTERS . 

149 

02 

LINE-COUNT 

PIC 

99 

150 

VALUE  0. 

151 

* 

152 

01 

FINAL-TOTAL-LINE. 

153 

02 

FILLER 

PIC 

X(10) 

154 

VALUE  '  TOTAL* . 

155 

02 

FILLER 

PIC 

X(51) 

156 

VALUE  SPACES. 

157 

02 

O-TOTAL-YEAR-TO-OATB-SALES 

PIC 

2(9) -99 

158 

02 

FILLER 

PIC 

XXX 

159 

VALUE  SPACES. 

160 

02 

O-TOTAL-CURRENT-SALES 

PIC 

Z(8> .99 

161 

02 

FILLER 

PIC 

X(1S) 

162 

VALUE  SPACES. 

163 

02 

O-TOTAL-CURRENT-COMN ISSXON 

PIC 

2(7) .99 

164 

02 

FILLER 

PIC 

X(20) 

165 

VALUE  SPACES. 

166 

167 

01 

AEPORT-LINE-1. 

168 

02 

FILLER 

PIC 

X(61> 

169 

VALUE  SPACES. 

170 

02 

FILLER 

PIC 

XflO) 

171 

VALUE  'COMMISSION*. 

172 

02 

FILLER 

PIC 

X(50) 

173 

VALUE  SPACES. 

174 

02 

FILLER 

PIC 

X(6) 

175 

VALUE  'PACE 

176 

02 

O-PAGE-NUMBER 

PIC 

999 

177 

VALUE  0. 

178 

02 

FILLER 

PIC 

XX 

179 

VALVE  SPACES. 

180 

181 

01 

REPORT- LINE- 2. 

182 

02 

FILLER 

PIC 

X(63) 

183 

VALUE  SPACES. 

184 

02 

FILLER 

PIC 

X(«) 

185 

VALUE  'REPORT*. 

186 

02 

FILLER 

PIC 

XC63I 

187 

VALUE  SPACES. 

188 

189 

01 

HEAOIMG-UNE-l. 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(4> 

02 

FILLER 

VALUE  'STORE1. 

PIC 

X(S) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(4) 

02 

FILLER 

VALUE  'DEPARTMENT' . 

PIC 

XUO) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(4) 

02 

FILLER 

VALUE  'SALESMAN'. 

PIC 

X(8) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(9) 

02 

FILLER 

VALUE  'SALESMAN'. 

PIC 

X(8) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(10) 

02 

FILLER 

VALUE  'YEAR  TO  DATE* . 

PIC 

X  ( 1 2) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(S» 

02 

FILLER 

VALUE  'CURRENT' . 

PIC 

X(7) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(4) 

02 

FILLER 

VALUE  'COMMISSION'. 

PIC 

X(10) 

02 

FILLER 

VALUE  SPACES. 

PIC 

xrs> 

02 

FILLER 

VALUE  'CURRENT*. 

PIC 

X(7) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(6) 

02 

FILLER 

VALUE  'MONTHS'. 

PIC 

X(6) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(8) 

HEADING-LINE-2. 

PIC 

X(4) 

02 

FILLER 

VALUE  SPACES. 

02 

FILLER 

VALUE  'NUMBER'. 

PIC 

X(6) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(18) 

02 

FILLER 

VALUE  'NUMBER'. 

PIC 

X(«) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(12) 

02 

FILLER 

VALUE  'NAME'. 

PIC 

X{4) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(l«) 

02 

FILLER 

VALUE  'SALES'. 

PIC 

X(5) 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(*> 

02 

FILLER 

VALUE  'SALES'. 

PIC 

X(S> 

02 

FILLER 

VALUE  SPACES. 

PIC 

X(8) 

02 

FILLER 

VALUE  'RATE*. 

PIC 

X(4) 
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2S4 

02 

PILLER 

PIC 

X(7) 

255 

VALUE  SPACES. 

256 

02 

PILLER 

PIC 

X<10) 

257 

VALUE  'COMMISSION*. 

258 

02 

PILLER 

PIC 

X(3) 

259 

VALUE  SPACES. 

260 

02 

PILLER 

PIC 

X  ( 8 ) 

261 

VALUE  'EMPLOYED*. 

262 

02 

PILLER 

PIC 

X(7) 

263 

VALUE  SPACES. 

264 

265 

01 

VALID-DATA-LINE. 

266 

02 

PILLER 

PIC 

X  (6) 

267 

VALUE  SPACES.  . 

268 

02 

O-STORE-MUMBER 

PIC 

29. 

269 

02 

PILLER 

PIC 

X  ( 9  J 

270 

VALUE  SPACES. 

271 

02 

O-OEPARTMENT 

PIC 

XX. 

272 

02 

PILLER 

PIC 

X(10) 

273 

VALUE  SPACES. 

274 

02 

O-SALESMAN-NUMBER 

PIC 

229. 

275 

02 

PILLER 

PIC 

X(6) 

276 

VALUE  SPACES. 

277 

02 

O-SALESMAN-NAME 

PIC 

X(20) . 

278 

02 

FILLER 

PIC 

X(6) 

279 

VALUE  SPACES. 

• 

280 

02 

O-YEAR-TO-DATE-SALES 

PIC 

2(6)  .99 

281 

02 

PILLER 

PIC 

X(5) 

282 

VALUE  SPACES. 

283 

02 

O-CURRENT-SALES 

PIC 

2(6) .99 

284 

02 

PILLER 

PIC 

X  (7) 

285 

VALUE  SPACES. 

286 

02 

O-COMMISS ION-RATE 

PIC 

.99. 

287 

02 

FILLER 

PIC 

X{7) 

288 

VALUE  SPACES. 

289 

02 

O-CURRENT-COMMISSION 

PIC 

2(5) .99 

290 

02 

PILLER 

PIC 

X(B) 

291 

VALUE  SPACES. 

292 

02 

0-M0NT8S-EMPL0YED 

PIC 

29. 

293 

02 

PILLER 

PIC 

X(10) 

294 

VALUE  SPACES. 

295 

296 

01 

INVALID-DATA-LINE . 

297 

02 

O-BAD-DATA 

PIC 

X(45>  . 

298 

02 

PILLER 

PIC 

X  ( 3  0) 

299 

VALUE  '  INVALID  DATA 

ON  THIS  CARD* . 

300 

02 

PILLER 

PIC 

X(57) 

301 

VALUE  SPACES. 

302 

303 

304 

305 

306  PROCEDURE  DIVISION. 

307 

308 

309  PRCPARC-PAYMENT-REPORT. 

310  OPEN  INPUT  CARD-PILE 

311  OUTPUT  PRINT-PILE. 

312  READ  CARD-PILE 

313  AT  END  MOVE  'NO'  TO  MORE-DATA-RBMAINS-PUG. 

314 

315  IP  M ORE-DA TA-REMAINS-PLAC  -  ‘YES* 

316  PERPORM  REPORT-HEADER-OUTPUT 

317  PERPORM  HEADING -OUT PUT 
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319 

319 

320 

321 

322 

323 

324 

325 

326 

327 

328 
?29 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 


PERFORM  COMMISSION-CALCULATION 

UNTIL  MORE-DATA-REMAINS-PLAG  -  'NO  *. 

PERFORM  CALCULATED- TOTALS -OUTPUT. 

CLOSE  CARD-FILE 
PRINT-FILE. 

STOP  RUN. 


•  CHECK  VARIABLES  TO  SEE  IF  THEY  CONTAIN  VALID  INFORMATION 
VALIDATION. 

IF  I-STORE-NUMBER  IS  NUMERIC 

AND  I-SALESMAN-NUMBER  IS  NUMERIC 
AND  I-YEAR-TO-DATE-SALES  IS  NUMERIC 
AND  I -CURRENT-SALES  IS  NUMERIC 
AND  I-COMM I S3 ION-RATE  IS  NUMERIC 
AND  I -MONTHS-EM PLOYED  IS  NUMERIC 
MOVE  'YES'  TO  VALID-DATA-FLAG 

ELSE 

MOVE  'NO*  TO  VALID-DATA-FLAG. 


•  MOVE  INPUT  INFORMATION  TO  WORKING  STORAGE 

•  VARIABLES 

DATA-HOVE. 

MOVE  I-STORE-NUMBER  TO  W-STORE-NUMBER. 

MOVE  I -DEPARTMENT  TO  W-DEPARTMENT. 

MOVE  I-SALESMAN-NUMBER  TO  W- SALESMAN-NUMBER . 

MOVE  I-YEAR-TO-DATE-SALES  TO  W-YEAR-TO-DATE-SALES. 
MOVE  I -CURRENT-SALES  TO  W-CURRENT-SALES. 

MOVE  I -COMM I SSI ON -RATE  TO  W-COMM I SSI ON-RATE. 

MOVE  I-MONTHS-EMPLOYEO  TO  W-MONTHS-EMPLOYED. 

CALCULATE-DEPARTMENT-BONUS . 

IF  W-DEPARTMENT  -  '01*  OR 
W-DEPARTMENT  -  ’02’ 

MOVE  DEPT-l-OR-2  TO  W-rEPARTMENT-BONUS 
ELSE  IF  W-DEPARTMENT  »  '06'  OR 
W-DEPARTMENT  •  '09' 

HOVE  DEPT-6-OR-9  TO  W-DEPARTHENT-BONUS 
ELSE  IF  W-DEPARTMENT  -  ’05'  OR 
W-DEPARTMENT  -  '07' 

MOVE  DEPT-5-0R-7  TO  W-DEPARTMENT-BONUS 
ELSE  IF  W-DEPARTMENT  -  '04' 

MOVE  DEPT-4  TO  W-DEPARTMENT-BONUS 

ELSE 

MOVE  DEPT-OTHER  TO  W-DEPARTMENT-BONUS. 

CALCULATE-VOLUN E-BONUS. 

COMPUTE  W-AVERAGE-MONTHLY-SALES  ROUNDED  - 
(  W-YEAR-TO-DATE-SALES  ♦  W-CURRENT-SALES  ) 

/  W-MONTHS-EMPLOYED. 

IF  W-AVERACE-MONTHLY-SAUS  <  500 
MOVE  LEVEL-1  TO  W- VOLUME-BONUS 
ELSE  IF  W-AVERAGE-MONTHLY-SALES  <  999.99 
MOVE  LEVEL-2  TO  W- VOLUME-BONUS 
ELSE  IF  W-AVERAGE-MONTHLY-SALES  <  1999.99 
MOVE  LEVEL- 3  TO  W-VOLUME-BONUS 

ELSE 

MOVE  LEVEL-4  TO  W-VOLUME-BONUS. 

COMM  X8S ION-CALCULATION . 


PERFORM  VALIDATION 


392 

393 

394 

395 

396 

397 
399 
399 

390 

391 

392 

393 

394 

395 

396 

397 
399 

399 

400 

401 

402 

403 

404 

405 

406 

407 
409 

409 

410 

411 

412 

413 

414 

415 

416 

417 
419 

419 

420 

421 

422 

423 

424 

425 

426 

427 
429 

429 

430 

431 

432 

433 

434 

435 

436 

437 
439 

439 

440 

441 

442 

443 

444 

445 


19  VALID-DATA-FLAG  -  •YES' 

PERFORM  DATA-HOVE 

PERFORM  CALCULATE-DEPARTMENT-BONUS 

PERFORM  CALCULATE- VOLUME-BONUS 

COMPUTE  W-CURRENT-COMNISSION  ROUNDED  -  W-CURRENT-SALES  • 

(  W-COMM I SSI ON-RATE  ♦  W-VOLUME-BONUS  ♦ 
W-DEPARTMENT-BONUS  ) 

ADO  W-YEAR-TO-DATE-SALES  TO  W-TOTAL-YEAR-TO-DATE-SALES 
ADD  W-CURRENT-SALES  TO  W-TOTAL-CURRENT-SALES 
ADO  W-CURRENT-COMMXSSION  TO  W-TOTAL-CURRENT-COHMISSION 
PERFORM  VALID-DATA-OUT PUT 

ELSE 

PERFORM  INVALID-DATA-OUT PUT* 

READ  CARD-FILE 

AT  END  MOVE  'NO'  TO  MORE-DATA-REMAXNS-FLAC. 
VALID-DATA-OUTPUT. 

MOVE  W-STORE-NUMBER  TO  O-STORE-NUMBER. 

MOVE  W-DEPARTMENT  TO  O-DEPARTMENT. 

MOVE  W-SALESHAN-NUMBER  TO  O-SALESMAN-NUMBER. 

MOVE  I-SALESMAN-NAME  TO  O-SALESMAN-NAME. 

MOVE  W-YEAR-TO-DATE-SALES  TO  0- YEAR-TO-DATE-SALES. 

MOVE  W-CURRENT-SALES  TO  O-CURRENT-SALES. 

MOVE  W-COMM I SSI ON-RATE  TO  O-COMM XSSI ON-RATE. 

MOVE  W-CURRENT-COMMISSXON  TO  O-CURRENT-COMMISSION. 

MOVE  W-MONTHS-EMPLOYED  TO  O-MONTHS-EMPLOYED. 

MOVE  I-SALESMAN-NAME  TO  O-SALESMAN-NAME. 

MOVE  VALID-DATA-LXNE  TO  LINE-RECORD. 

WRITE  LINE-RECORD  AFTER  ADVANCING  1  LINES. 

ADD  1  TO  LINE-COUNT. 

IF  LINE-COUNT  IS  GREATER  THAN  10 
MOVE  0  TO  LINE-COUNT 
PERFORM  REPORT-HEADER-OUTPUT 
PERFORM  BEADING-OUTPUT. 

INVALID-DA TA-OUTPUT. 

MOVE  I -CARD-DATA  TO  0-BAD-DATA. 

MOVE  INVALID-DATA-LXNE  TO  LINE-RECORD. 

WRITE  LINE-RECORD  AFTER  ADVANCING  1  LINES. 

ADD  1  TO  LINE-COUNT. 

IF  LINE-COUNT  IS  GREATER  THAN  10 
’  MOVE  0  TO  LINE-COUNT 

PERFORM  REPORT-HEADER-OUTPUT 
PERFORM  BEADING-OUTPUT. 

READING-OUTPUT. 

MOVE  HEADING-LINE- 1  TO  LINE-RECORD. 

WRITE  LINE-RECORD  AFTER  ADVANCING  1  LINES. 

MOVE  HEADING-LINE- 2  TO  LINE-RECORD. 

WRITE  LINE-RECORD  AFTER  ADVANCING  1  LINES. 

MOVE  SPACES  TO  LINE-RECORD. 

WRITE  LINE-RECORD  AFTER  ADVANCING  2  LINES. 

ADD  4  TO  LINE-COUNT. 

CALCULATED-TOTALS-OVITPUT  . 

MOVE  W-TOTAL-YEAR-TO-DATE-SALES  TO  O-TOTAL-YEAR-TO- DATE-SALES 
MOVE  W-TOTAL*CURRCNT-SALES  TO  O-TOTAL-CURRENT-SALES. 

HOVE  W-TOTAL-CURRENT-COHMXSSION  TO  O-TOTAL-CURRENT-COMHISSXON 
MOVE  FINAL-TOTAL-LINE  TO  LINE-RECORD. 

WRITE  LINE-RECORD  AFTER  ADVANCING  2  LINES. 
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446  REPORT-HEADER-OUTPOT. 

447  ADO  1  TO  O-PAGE-NUMSER. 

448  MOVE  REPORT-LINE- 1  TO  LIME-RECORD. 

449  WRITE  LINE-RECORD  AFTER  ADVANCING  TO-TOP-O 

450  MOVE  REPORT-LIME-2  TO  LINE-RECORD. 

451  WRITE  LINE-RECORD  AFTER  ADVANCING  1  LINES. 

452  MOVE  SPACES  TO  LIME-RECORD. 

453  WRITE  LINE-RECORD  AFTER  ADVANCING  3  LINES. 

454  MOVE  4  TO  LINE-COUNT. 

455 


A 


j 


I* 

9 


-PAGE. 
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PROGRAM  6 


IDENTIFICATION  DIVISION. 

PROGRAM-ID.  MAINTMFS. 

REMARKS.  THIS  PROGRAM  IS  ADAPTED  PROM  YOUR DAN'S  •LEARNING 
TO  PROGRAM  IN  STRUCTURED  COBOL*. 

(1)  THE  PROGRAM  AS  PUBLISHED  DID  NOT  WORK.  THE  LAST 
PAIR  OF  APPLICATION  CARDS  WAS  IGNORED.  IP  THERE 

WAS  NO  LAST  PAIR  (EMPTY  PILE)  THE  PROGRAM  BOMBED. 

THIS  ERROR  WAS  FIXED  BY  ADDING  ANOTHER  FILE-CONTROL 
FLAG  AND  ADDING  LOGIC  IN  * B1 -GET- A- PAIR. . .• 

(2)  THE  NOTE  ABOUT  CHECKING  PAIR  VALIDITY 

IN  PARAGRAPH  *A2-UPDATE  MASTER*  SHOULD  BE  REPEATED 
IN  THE  ANALOGOUS  PARAGRAPH  *A4-ADD-REMAINING-CARDS* . 

(3)  IF  THE  FIRST  CARD  IS  INVALID,  ITS  LOG  ENTRY 
WOULD  HAVE  BEEN  WRITTEN  BEFORE  THE  LOG  PILE  HEADER. 

(4)  THE  PUBLISHED  PROGRAM  CONTAINED  MUCH  EXTRANEOUS 
CODE.  THE  REASON  FOR  SOME  OP  THIS  WAS  THE  FREE  USE  OF 
THE  *  COPY*  VERB.  THESE  PRODUCED  MANY  UNNECESSARY 
MUTANTS,  AND  HAVE  BEEN  COMMENTED  OUT  WITH  **••*. 

(5)  THE  PROGRAM  DID  NOT  DO  ANYTHING  SENSIBLE  WREN 
THE  ENO-OF-FILE  WAS  ENCOUNTERED  AFTER  THE  FIRST  OP  A 
PAIR  OF  CARDS. 


ENVIRONMENT  DIVISION. 
CONFIGURATION  SECTION. 
SOURCE-COMPUTER.  PRIME. 
OBJECT-COMPUTER.  PRIME. 
INPUT-OUTPUT  SECTION. 
FILE-CONTROL. 

SELECT  APPLICATION-CARDS-FILE 
SELECT  UPDATE-LISTING 
SELECT  CREDIT-MASTER-OLD-PILE 
SELECT  CREDIT-MASTER-NEW-PILE 


ASSIGN  TO  INPUT1. 
ASSIGN  TO  OUTPUT!. 
ASSIGN  TO  INPUT2. 
ASSIGN  TO  0UTPUT2. 


DATA  DIVISION. 
FILE  SECTION. 


APPLICATION-CARDS-FILE 

RECORD  CONTAINS  80  CHARACTERS 

LABEL  RECORDS  ARE  OMITTED 

DATA  RECORD  IS  NAM E -AODR ESS -AND- PHONE-IN . 


41 

01 

NAME-ADDRESS-AND-PHONE-IN. 

42 

OS 

NAME-AND-ADDRESS-I N . 

43 

10  NAME-IN 

PIC  X(20) . 

44 

•  •• 

10  ADDRESS-IN. 

4S 

•  •• 

15  STREET- IN 

PIC  X(20) . 

44 

•  •• 

15  CITY-IN 

PIC  X (13) . 

47 

#•* 

15  STATE-XN 

PIC  XX. 

48 

•  «# 

15  ZIP-IN 

PXC  X(5) . 

49 

10  ADDRESS-IN 

PXC  X(40) • 

SO 

05 

PHONE-IN 

PIC 

X(U). 

SI 

05 

FILLER 

PIC 

X. 

S2 

05 

CHANGE-CODE-IN 

PXC 

XX. 

S3 

05 

ACCT-NUM-IN1 

PIC  9(6). 

54 

S3 

PO 

UPDATE-LISTING 

56 

RECORD  CONTAINS  132  CHARACTERS 

LABEL  RECORDS  ARE  OMITTED 
DATA  RECORD  IS  PRINT-LINE-OUT. 
PRINT-LINE-OUT 


PIC  X(X32) . 


CREDIT-MASTER-OLD-PILE 
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62 

RECORD 

CONTAINS  127  CHARACTERS 

63 

LABEL 

RECORDS  ARE  STANDARD 

64 

DATA  RECORD  IS  CREDIT-MASTER -RECORD. 

» 

65 

02 

CREDIT-MASTER-OLD-RECORD. 

66 

05 

ACCT-NUM-MAS-OLD 

PIC 

9(«1  . 

67 

THE 

SUBFIELDS  ARE  NEVER  REFERRRED  TO 

IN  THB  PROGRAM 

68 

**• 

USE  FILLER  INSTEAD 

69 

*♦* 

05 

NAME-AND-ADDRESS-MAS-OLD. 

70 

•  ** 

10 

NAME-MAS-OLD 

PIC 

X (20) . 

71 

#•* 

10 

STREET-MAS-OLD 

PIC 

X(20)  . 

72 

•  ** 

10 

CITY-MAS-OLD 

PIC  X  (131  . 

73 

10 

STATE-MAS-OLD 

PIC 

XX. 

74 

10 

ZIP-MAS-OLD 

PIC 

9(5)  . 

75 

05 

PHONE-MAS-OLD. 

76 

*•* 

10 

AREA-CODE-MAS-OLD 

PIC 

9(3)  . 

77 

78 

79 

**• 

*«•« 

10 

NUMBER-MAS-OLD 

PIC 

9(7)  . 

05 

FILLER 

PIC 

X{70). 

90 

THE 

SUBFIELOS  ARE  NEVER  REFERRED  TO  IN  THE  PROGRAM. 

81 

05 

CREDIT-INPO-MAS-OLD. 

82 

10 

SEX-MAS-OLD 

PIC 

X. 

83 

*«« 

10 

MARITAL-STATUS-MAS-OLD 

PIC 

X. 

84 

*«* 

10 

NUMBER-DEPENS-MAS-OLD 

PIC 

99. 

85 

«** 

10 

INCOME-HUNOREDS-MAS-OLD 

PIC 

9(3). 

83 

«•« 

10 

Y  EARS -EMPLOYED-MAS-OLD 

PIC 

99. 

87 

*•* 

10 

OWN-OR-R ENT-MAS-OLD 

PIC 

X. 

88 

*** 

10 

MORCACE-OR-RENTAL-MAS-OLD 

PIC 

9(3). 

89 

*•* 

10 

OTHER-PAW  ENTS-MAS-OLD 

PIC 

9(3)  . 

90 

05 

CREDIT-INFO-MAS -OLD 

PIC 

X  (16)  . 

91 

05 

ACCOUNT- INFO-M AS-0  LD. 

92 

10 

DISCR-INCOME-KAS-OLD 

PIC 

S9  (3)  . 

93 

««• 

10 

CREDIT-LIMIT-OLD 

PIC 

9(4)  . 

94 

10 

FILLER 

PIC 

S9(3) . 

95 

10 

FILLER 

PIC 

9(4). 

96 

10 

CURRENT-BALANCE-OWING-OLD 

PIC 

S9 (61V99. 

97 

98 

99 

05 

SPARE-CHARACTERS-OLD 

PIC 

X(20) . 

FD 

credit-haster-new-file 

100 

record 

CONTAINS  127  CHARACTERS 

101 

label  records  are  standard 

102 

DATA  RECORD  IS  CREDIT-MASTER-RECORD- 

103 

01 

CREDIT-MASTER-NEW-RECORD. 

104 

05 

ACCT -NUN-MAS-NEW 

PIC 

9(6)  . 

105 

t** 

05 

NAME-AND-ADDRESS-MAS-NEW. 

106 

10 

NAME-MAS-NEW 

PIC 

X  (20)  . 

107 

10 

STREET-MAS-NEW 

PIC 

X(20). 

108 

*»• 

10 

CITY -MAS-NEW 

PIC 

Xf  13)  . 

109 

10 

STATE-MAS-NEW 

PIC 

XX. 

110 

10 

ZIP-MAS-NEW 

PIC 

9(5). 

111 

05 

NAME-AND-ADDRESS-MAS-NEW 

PXC 

X(60). 

112 

05 

PHONE-MAS-NEW. 

113 

10 

AREA-CODE-MAS-NEW 

PIC 

9(3). 

114 

10 

NUM8R-MAS-NEW 

PIC 

9(7). 

115 

OS 

CREDIT- INFO-MAS-NCW. 

11# 

10 

SEX-MAS-NEW 

PIC 

X. 

117 

10 

MARITA  L-STATUS-MAS-NEW 

PIC 

X. 

118 

10 

NUMBER-DEPENS-MAS-MEW 

PIC 

99. 

119 

10 

I NCOM  E-HUNDREDS-MAS-MEW 

PIC 

9(3) . 

120 

10 

YEARS-EMPLOYED-MAS-NCW 

PIC 

99. 

121 

10 

OWW-OR-RENT-MAS-NEW 

PIC 

X. 

122 

10 

MORGACE-OR-RENTAL-MAS-WCW 

PIC 

9(3)  . 

123 

10 

OTHER-PAWENTS-MAS-NEW 

PXC 

9(3). 

124 

05 

ACCOUNT-XNFO-MAS-NEW. 

125 

10 

DI  SCR- INCOME-MAS-NEW 

PIC 

S9(3). 

PIC  S9(3) 
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126 

10  CREDIT-LIMIT-MAS-NEW 

PIC 

9(4)  . 

12? 

10  CURRENT-BALANCE-OWING 

-NEW 

PIC 

S9(6) V99. 

126 

05 

SPARE-CHARACTERS-NEW 

PIC 

X (20) • 

129 

130 

WORKING-STORAGE  SECTION. 

131 

132 

01 

CREDIT-INFORMATION-IN. 

133 

05 

CARD-TYPE-IN 

PIC 

X. 

134 

05 

ACCT-NUN-IN2 

PIC 

9(6)  . 

135 

05 

FILLER 

PIC 

X. 

136 

05 

CREDIT-INFO-IN 

PIC 

X(22) . 

137 

05 

FILLER 

PIC 

X (50)  . 

138 

139 

01 

COMMON-WS. 

140 

OS 

CARDS-LEFT 

PIC 

X(3)  . 

141 

05 

NEXT-CARD -THERE 

PIC 

X ( 3)  . 

142 

05 

OLD-MASTER-RECORDS-LEFT 

PIC 

X  ( 3  >  . 

143 

05 

NEW-MASTER-RECORDS-LEFT 

PIC 

X  ( 3)  . 

144 

05 

FIRST-CARD 

PIC 

X(4)  . 

145 

05 

SECOND-CARD 

PIC 

X  (4)  . 

146 

05 

ACCT-NUM -MATCH 

PIC 

X(4)  . 

14? 

OS 

PAIR-VALIDITY 

PIC 

X(4)  . 

148 

149 

01 

L0G-HEADER-WSA1. 

ISO 

OS 

FILLER 

PIC 

X ( 4 7)  VALUE  SPACES. 

151 

OS 

FILLER 

PIC 

X(38) 

152 

VALUE  'LOG  OF  ADDITIONS  DELETIONS  AND  CHANGES'. 

153 

05 

FILLER 

PIC 

X(47)  VALUE  SPACES. 

154 

155 

•  ♦•03 

,  HEAOER-WSAS. 

156 

•  •• 

05  TILLER 

PIC  X f 5 1 > 

VALUE  SPACES 

157 

•  •• 

05  TITLE 

PIC  XC30J 

158 

•  •• 

VALUE  'CONTENTS  OF 

CREDIT 

MASTER  FILE'. 

159 

•  •• 

05  FILLER 

PIC  X (51 1 

VALUE  SPACES 

160 

01 

APPLICATI0N-0ATA-WSB2. 

161 

05 

NAMK-AND-ADDRESS-WS . 

162 

10  NAME-WS 

PIC 

X(20) . 

163 

•  •• 

10  ADDRESS-WS. 

164 

•  •• 

15  STREET-WS 

PIC 

X ( 20)  . 

165 

•  •• 

15  CITY-WS 

PIC 

X  (1 3)  . 

166 

••• 

15  STATE-WS 

PIC 

XX. 

16? 

•  •• 

15  IIP-WS 

PIC 

X  (5)  . 

168 

10  ADDRESS-WS 

PIC 

X  ( 4  0 )  . 

169 

05 

PHONE-WS  . 

170 

10  AREA-CODE-WS 

PIC 

9(3)  . 

171 

10  NUMBR-WS 

PIC 

X (8)  . 

172 

05 

FILLER 

PIC 

X  VALUE 

SPACE. 

173 

05 

CHANGE-CODE-WS 

PTC 

XX. 

174 

05 

ACCT-N  UM-WS 

PIC 

9(6)  . 

1?5 

05 

CREDIT-INFO-WS. 

176 

10  SEX-WS 

PIC 

X. 

177 

•• 

88  MALE  VALUE 

•M'  . 

178 

•• 

86  FEMALE  VALUE 

•f. 

179 

10  FILLER 

PIC 

X. 

160 

10  MARITAL*STATUS-WS 

PIC 

X. 

181 

•• 

88  SINGLE  VALUE 

•S'. 

182 

•# 

66  MARRIED  VALUE 

•M*. 

183 

•# 

88  DIVORCED  VALUE 

•D'  . 

184 

•• 

86  WIDOWED  VALUE 

•W»  . 

185 

10  FILLER 

PIC 

X. 

186 

10  NUMBER-DEPENS-WS 

PIC 

9. 

187 

10  FILLER 

PIC 

X. 

188 

10  INCOME-NUNOREDS-WS 

PIC 

9(3). 

189 

10  FILLER 

PIC 

X. 

i 
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190 

10  YEARS-EMPLOYED-WS 

PIC 

99. 

191 

10  FILLER 

PIC 

X. 

192 

10  OWN-OR-RENT-WS 

PIC 

X. 

193 

•• 

88  OWNED  VALUE  *0*. 

194 

•  • 

88  RENTED  VALUE  'R* . 

195 

10  FILLER 

PIC 

X. 

194 

10  MORGAGE-OR-RENTAL-WS 

PIC 

9(3)  . 

197 

10  FILLER 

PIC 

X. 

198 

10  OTHER-PAYMENTS-WS 

PIC 

9(3)  . 

199 

200 

01 

UPDATE-MESSAGE-AREA-WSB2. 

201 

05 

UPDATE-MESSACE-AREA 

PIC 

X  (1 5) 

202 

203 

01 

CREDIT-MASTER- PR INT-LINE. 

204 

05 

FILLER 

PIC 

X  (4) 

VALUE  SPACES. 

205 

05 

CREDIT-MASTER-OUT 

PIC 

X  C 1 28) 

• 

206 

207 

01 

UPDATE-RECORD-PRINT-LINE . 

208 

05 

FILLER 

PIC 

X  (4) 

VALUE  SPACES. 

209 

05 

APPLICATION-DATA-OUT 

PIC 

X(1  02) 

« 

210 

05 

FILLER 

PIC 

X  (4) 

VALUE  SPACES. 

211 

05 

MESSAGE-AREA-OUT 

PIC 

X(15) . 

212 

213 

01 

DISCR- 1 NCOME-C A  LC- P I ELDS-WSC8 . 

214 

05 

annual-income-ws 

PIC 

9(5)  . 

215 

05 

ANNUAL-TAX-WS 

PIC 

9(5)  . 

216 

05 

TAX-RATE-WS 

PIC 

9V99 

VALUE  0.25. 

217 

05 

MONTHS- IN- YEAR 

PIC 

99 

VALUE  12. 

218 

05 

MONTHLY-NET-INCOME-WS 

PIC 

9(4)  . 

219 

05 

monthly-paynents-ws 

PIC 

9(4)  . 

220 

05 

DISCR-INCOME-WS 

PIC 

S9  ( 3)  . 

221 

222 

01 

CREDIT-LIMIT-CALC-FIELDS-WSC9. 

223 

05 

CREDIT-FACTOR 

PIC 

9. 

224 

05 

FACTOR 1 

PIC 

9 

VALUE  1. 

225 

05 

FACTOR 2 

PIC 

9 

VALUE  2. 

226 

05 

FACTOR 3 

PIC 

9 

VALUE  3. 

227 

05 

FACTOR4 

PIC 

9 

VALUE  4. 

228 

05 

FACTOR 5 

PIC 

9 

VALUE  5. 

229 

05 

CREDIT-LIHIT-WS 

PIC 

9(4)  . 

230 

05 

UPPER-LIHIT-WS 

PIC 

9(4) 

VALUE  2500. 

231 

•  •• 

NEVER  USED 

232 

•  •• 

05 

TOTAL-CREDIT-CIVEN-WS 

PIC 

9(7)  . 

233 

234 

01 

ASSEMBLE-TEL-NUM-WSD1. 

235 

05 

TEL-NUMBR-WITH -HYPHEN. 

236 

10  EXCHANGE- IN 

PIC 

9(3)  . 

237 

10  FILLER 

PIC 

X. 

238 

10  FOUR-DIGIT-NUMBR-IN 

PIC 

9(4)  . 

239 

05 

TEL-NUMBR-W ITHOUT-HYPHEN . 

240 

10  EXCHANGE 

PIC 

9(3)  . 

241 

10  FOUR-DIG IT-NUMBR 

PIC 

9(4)  . 

242 

243 

01 

CARD-ERROR-LINEl-WS. 

244 

05 

FILLER 

PIC 

X  ( 5 ) 

VALUE  SPACES. 

245 

05 

FILLER 

PIC 

X  ( 1 2) 

246 

VALUE  'FIRST  CARD 

247 

05 

FIRST-CARD-ERR1 

PIC 

X  (4)  . 

248 

05 

FILLER 

PIC 

XX  VALUE  SPACES. 

249 

05 

NAME-ERR1 

PIC 

X  (20) 

250 

05 

ADDRESS-ERR1 

PIC 

X(40) 

251 

05 

PHONE-ERR1 

PIC 

X(ll) 

252 

05 

FILLER 

PIC 

X(3) 

VALUE  SPACES. 

253 

05 

ACCT-NUM-ERR 1 

PIC 

9(5) . 

254 

255  01  CARD-ERROR-LINE2-WS. 


256 

05 

FILLER 

PIC  X  C  5 ) 

VALUE  SPACES. 

257 

05 

FILLER 

PIC  X(12) 

258 

VALUE  'SECOND  CARD  '. 

259 

05 

SEC0ND-CARD-ERR2 

PIC  X  (4)  . 

260 

05 

FILLER 

PIC  X(2) 

VALUE  SPACES 

261 

05 

CREDIT-INFO-ERR2 

PIC  X(80> 

262 

05 

MCSSAGE-ERR-LINE-2 

PIC  Xf29) 

VALUE  SPACES 

263 

264  PROCEDURE  DIVISION. 

265 

266  AO-MAIN-BODY. 

267  PERFORM  Al-INITIALIZE. 

268  PERFORM  A2-U PDATE-MASTER 

269  UNTIL  OLD-MASTER-RECORDS-LEFT  -  'NO  • 

270  OR  CARDS-LEFT  ■  'NO  • . 

271  IF  CARDS-LEFT  -  'NO  ' 

272  *  THERE  ARE  MORE  OLD  MASTER  REC 

273  PERFORM  A3-COPY-REMAINXNC-OLD-MASTER 

274  UNTIL  OLD-MASTER-RECORDS-LEFT  -  'NO  * 

275  ELSE 

276  *  THERE  ARE  NO  MORE  CARDS,  SO 

277  PERFORM  A4 -ADD-REMAINING -CARDS 


278 

279 

280 
281 
282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 


UNTIL  CARDS-LEFT  -  'NO  • .  . 


CODE  TO  LIST  THE  CONTENTS  OF  THE  NEW  MASTER  HAS  BEEN  OMITTED. 
IT  WOULD  HAVE  REQUIRED  CLOSING  THE  NEW  MASTER  AND  REOPENING 
IT  FOR  INPUT.  THIS  IS  BEYOND  THE  ABILITIES  OF  CHS.l 
THE  DELETION  AMOUNTS  TO  ABOUT  20  LINES  OF  CODE. 


PERFORM  A7-END-0F-J0B. 

STOP  RUN. 

A1 -INITIALIZE. 

OPEN  INPUT  APPLICATION-CARDS-FILE 

CREDIT-MASTER-OLD-FILE 
OUTPUT  CRED IT-MASTER-N  EW-F I LE 

UPDATE-LISTING. 

***  USELESS  INITIALIZATIONS  HAVE  BEEN  COMMENTED  OUT 
•••  MOVE  SPACES  TO  FIRST-CARD. 

MOVE  SPACES  TO  SECOND-CARD. 

*•*  MOVE  SPACES  TO  ACCT-NUM -MATCH. 

MOVE  SPACES  TO  PAIR-VALIDITY. 

•••  MOVE  ZEROES  TO  ANNUAL-INCOME-WS. 

•••  MOVE  ZEROES  TO  ANNUA L-TAX-WS. 

•••  MOVE  ZEROES  TO  MONTHLY-NET- I NCOME-WS. 

•••  MOVE  ZEROES  TO  MONTHLY-PA YMENTS-WS. 

•**  MOVE  ZEROES  TO  DISCR-INCOHE-WS. 

*•*  MOVE  ZEROES  TO  CREDIT-FACTOR. 

**•  MOVE  ZEROES  TO  CREDIT-LIMIT-WS. 

***  MOVE  ZEROES  TO  TOTAL-CREDXT-CXVEN-WS. 

MOVE  'YES'  TO  CARDS-LEFT. 

MOVE  'YES'  TO  NEXT-CARD-THSRE. 

MOVE  'YES'  TO  OLD-WASTER-RfCOROS-LBFT. 

••  THE  FOLLOWING  STATEMENT  WAS  MOVED  HERE  FROM  THE  END  OF  THE 
••  PARAGRAPH,  SO  THAT  THE  HEADER  WOULD  BE  WRITTEN  BEFORE  THE 
••  FIRST  LOC  RECORD,  IF  THE  FIRST  CARD  PAIR  IS  INVALID. 

WRITE  PRINT-LINE-OUT  FROM  LOG-REAOER-WSAl 

AFTER  ADVANCING  3  LINES. 

REAO  APPLICATION-CARDS-FILE 

AT  END  MOVE  'NO  '  TO  NEXT-CARO-TRERB. 

PERFORM  B1-GET-A-PAXR-0F-CARDS-XNT0-W8  THRU  Bl-EXIT. 

•  FIRST  PAIR  OF  CARDS  IN  M8<  FIRST  CARD  OF  SECOND  FAIR  IN  BUFFER 


170 


318 

319 

320 

321 

322 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 
34  3 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 
3  56 

357 

358 
3  59 
360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 
177 
378 

179 

180 
'61 


READ  CREDIT-MASTER-OLD-FILE 

AT  END  MOVE  ’NO  *  TO  OLD-MASTER-RECORDS-LEPT. 

•  FIRST  OLD  MASTER  RECORD  IS  IN  BUFFER 

A2-UPDATE-MASTER. 

•  BEFORE  COMPARING  THE  UPDATE  WITH  THE  MASTER,  WE  MUST  CHECK 

•  THAT  WE  HAVE  A  VALID  PAIR  OF  CARDS  -  IF  YOUR  PROGRAM  DOES 

•  NOT  MAKE  THIS  TEST,  IT  WILL  ONLY  WORK  WITH  VALID  PAIRS  OF 

•  CARDS. 

IF  PA TR- VALIDITY  •  'BAD  * 

PERFORM  Bl-GET-A-PAIR-OF-CARDS-INTO-WS  THRU  Bl-EXIT 
ELSE  IF  ACCT-NUM-WS  IS  GREATER  THAN  ACCT-NUM-MAS-OLD 

•  ACCT-NUM-WS  IS  CARD  ACCOUNT  NUMBER 
MOVE  CREDIT-MASTER-OLD-RECORD  TO 

CREDIT-MASTER-NEW-RECORD 
WRITE  CREDIT-MASTER-NEW-RECORD 
READ  CREDIT-MASTER-OLD-FILE 

AT  END  MOVE  *NO  1  TO  OLD-MASTER-RECORDS-LEPT 
ELSE  IF  ACCT-NUM-WS  -  ACCT-NUM-MAS-OLD 
PERFORM  B2-CHANGE-QR-DELETE-M ASTER 

PERFORM  Bl-GET-A-PAIR-OF-CARDS-INTO-WS  THRU  Bl-EXIT 
READ  CREDIT-M ASTER- OLD- FILE 

AT  END  MOVE  ’NO  •  TO  OLD-MASTER-RECORDS-LEPT 

ELSE 

•  ACCT-NUM-WS  IS  LESS  THAN 

•  ACCT-NUM-MAS-OLD 
PERFORM  B3 -ADD-NEW-MASTER 

PERFORM  Bl-GET-A-PAIR-OF-CARDS-INTO-WS  THRU  Bl-EXIT. 

A  3 -COPY-REMA IN ING-0  LD-M ASTER . 

MOVE  CREDIT-MASTER-OLD-RECORD  TO 
CREDIT-MASTER-NEW-RECORD 
WRITE  CREOIT-MASTER-NEW-RECORD. 

READ  CREOIT-MASTER-OLD-FILE 

AT  END  MOVE  ’NO  *  TO  OLD-MASTER-RECORDS-LEPT.  . 

A4-ADD-REMAINING-CARDS . 

IF  PAIR-VALIDITY  -  'BAD  '  NEXT  SENTENCE 
ELSE  PERFORM  B3- ADD-NEW-MASTER. 

PERFORM  Bl-GET-A-PAIR-OP-CARDS-INTO-WS  THRU  Bl-EXIT. 
A7-END-0F-J0B. 

CLOSE  APPLICATION-CARDS-PILE 
CREDIT-MASTER-OLD-FILE 
CREDIT-MASTER-NEW-FILE 
UPDATE-LISTING. 

Bl-GET-A-PAIR-OF-CARDS-INTO-WS. 

IF  NEXT-CARD-THERE  -  'NO  * 

MOVE  'NO  ’  TO  CARDS-LEFT 
CO  TO  Bl-EXIT. 

PERFORM  f  ’EDIT-FIRST-CARD. 

PERFORM  C.  -MOVE-FIRST-CARD-TO-WS. 

READ  APPLICATION-CARDS -FILE  INTO  CREDIT-INPORMATIOW-IH 
AT  END  MOVE  'NO  •  TO  CARDS-LEFT, 

MOVE  SPACES  TO  CREDIT-INFORMATION-XN 
ACCT-NUM -MATCH 
MOVE  'NONE'  TO  SECOND-CARD 
PERFORM  C4-PLUSH-CARDS-TO-ERROR-LINES 
GO  TO  Bl-EXIT. 

PERFORM  C3-EOIT-8ECOND-CARD. 

IF  (FIRST-CARD  -  'GOOD') 

AND  (SECOND-CARD  •  'GOOD') 

AND  ( ACCT-NUH-M ATCH  •  'GOOD') 
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392 

383 

394 

38S 

396 

387 

388 

389 

390 

391 

392 

393 

394 

395 

396 

397 

398 

399 

400 

401 

402 

403 

404 

405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 

422 

423 

424 

425 

426 

427 
4  28 

429 

430 

431 

432 

433 

434 

435 

436 

437 

438 

439 

440 

441 

442 

443 

444 

445 


MOVE  'GOOD'  70  PAIR- VALIDITY 

MOVE  CREDIT-INFO-IN  TO  CREDIT- INFO-WS 

ELSE 

MOVE  'BAD  •  TO  PAIR-VALIDITY 
PERFORM  C4-FLUSH-CARDS-TO-ERROR-LINES. 

READ  APPL ICATION -CARDS- FILE 

AT  END  MOVE  'NO  1  TO  MEXT-CARD-THERR. 

Bl-EXIT.  EXIT. 

B2-CHANGE-OR-DELETE-MASTER. 

IF  CHANGE-CODE-WS  -  'CH* 

PERFORM  C5-M ERGE-U  PDATE-W ITH-OLD-M AST 
MOVE  'RECORD  CHANGED*  TO  UPDATE-MESSAGE-AREA 
PERFORM  C6-L0G-ACTI0N 
WRITE  CREDIT-MASTER-NEW-RECORD 
ELSE  IF  CHANGE-CODE-WS  -  'DE* 

1  CHECK  IF  DELETE  IS  VALID 

IF  CREDIT-INFO-WS  IS  EQUAL  TO  SPACES 

MOVE  'RECORD  DELETED'  TO  UPQATE-MESSACE-AREA 
PERFORM  C6-LOG-ACTIOM 

ELSE 

MOVE  'REC  NOT  DELETED'  TO  UPDATE-MESSAGE-AREA 

MOVE  CREDIT-MASTER-OLD-RECORD  TO 

CREDIT-MASTER-NEW-RECORD 

PERFORM  C6-L0G -ACTION 

WRITE  CREDIT-MASTER-NEW-RECORD 

ELSE 

MOVE  'BAD  CHANGE  CODE*  TO  UPDATE-MESSAGE-AREA 

MOVE  CREDIT-MASTER-OLD-RECORD  TO  CREDIT-MASTER-NEW-RECORD 

PERFORM  C6-L0G-ACTI0N 

WRITE  CREDIT-MASTER-NEW-RECORD. 

B  3-ADD-N EW-MASTER . 

PERFORM  C8-CALC-DISCRETNRY-INCOME. 

PERFORM  C9-CALC-CREDIT-LIMIT. 

PERFORM  Cl O-ASSEMB  LE -NEW-MASTER-RECORD. 

MOVE  'RECORD  ADDED  '  TO  UPDATE-MESSAGE-AREA. 

PERFORM  C6- LOG -ACT I ON. 

WRITE  CREDIT-MASTER-NEW-RECORD. 

Cl-EDIT-PIRST-CARD. 

MOVE  'GOOD'  TO  FIRST-CARD. 

IF  NAME-IN  IS  EQUAL  TO  SPACES 

MOVE  '•**  NAME  MISSING  •*•'  TO  NAME-IN 
MOVE  'BAD  •  TO  FIRST-CARO. 

IF  ADDRESS-IN  IS  EQUAL  TO  SPACES 

MOVE  '•••  ADDRESS  MISSING  ••••  TO  AOORESS-IN 
MOVE  'BAD  '  TO  FIRST-CARD. 

IF  PHONE-IN  IS  EQUAL  TO  SPACES 

MOVE  'NO  PHONE  •••  TO  PHONE-IM 
MOVE  'BAD  •  TO  FIRST-CARD. 

C 2 -MOVE- F I RST-CARD-TO-WS . 

MOVE  NAME-IN  TO  MAME-WS. 

MOVE  ADDRESS-IN  TO  ADDRES8-W8. 

MOVE  PHONE-IN  TO  PH0NE-W8. 

MOVE  CHANGE-CODE- IN  TO  CHANGE-CODE-WS. 

MOVE  ACCT-NUM-XN)  TO  ACCT-NUM-WS. 

C3-EDXT-SECOND-CARD. 

MOVE  'GOOD'  TO  SECOND-CARD. 

MOVE  'GOOD'  TO  ACCT-NUM -MATCH. 

IF  CARD-TYPE-IN  IS  NOT  EQUAL  TO  'C* 
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MOVE  'BAD  '  TO  SECOND-CARD. 

IF  ACCT-NUM-IN2  IS  NOT  EQUAL  TO  ACCT-NUM-WS 
MOVE  'BAD  '  TO  ACCT-NUM-NATCH. 

C4-FLUSH-CARDS-TO-ERROR-LINES. 

MOVE  FIRST-CARD  TO  FIRST-CARD-ERR1 . 

MOVE  NAME-WS  TO  NAME-ERRI. 

MOVE  ADDRESS-WS  TO  ADDRESS-ERR1 . 

MOVE  PHONE-WS  TO  PHONE-ERR1. 

MOVE  ACCT-NUM-WS  TO  ACCT-NUM-ERR1 . 

MOVE  SECOND-CARD  TO  SECOND-CARD-ERR2. 

>*  MOVE  CREDIT-INFO-WS  TO  CREDIT-INFO-ERR2. 

'*  THE  PREVIOUS  LINE  WAS  IN  ERROR  (BY  A  SINGLE  MUTATION)  IN  THE 
1  *  PUBLISHED  PROGRAM.  THE  CORRECT  STATEMENT  IS: 

MOVE  CREDIT-INFO-IN  TO  CREDIT- I NFO-ERR2. 

IF  ACCT-NUM -MATCH  -  'BAD  • 

MOVE  'ACCOUNT  NUMBERS  DO  NOT  MATCH’ 

TO  MESSAGE-ERR-LINE-2 

ELSE 

MOVE  SPACES  TO  MESSAGE-ERR-LINE-2. 

'**  MOVE  SPACES  TO  PRINT-LINE-OUT. 

WRITE  PRINT-LINE-OUT  FROM  CARD-ERROR-LINE 1-WS 
AFTER  ADVANCING  3  LINES. 

>*•  MOVE  SPACES  TO  PRINT-LINE-OUT. 

WRITE  PRINT-LINE-OUT  FROM  CARD-ERROR-LINE2-WS 
AFTER  ADVANCING  I  LINES. 


C  5-M  ERGE-U  PDATE-W I TH-0  LD-M AST . 

MOVE  ACCT-NUM-MAS-OLD  TO  ACCT-NUM-MAS-NEW. 

MOVE  NAME-AND-ADDRESS-WS  TO  NAME-AND-ADDRESS-MAS-NEW. 
MOVE  AREA-COOE-WS  TO  AREA-CODE-MAS-NEW. 

PERFORM  DI-REMOVE-HYPHEN-FROM-TEL-NUM . 

*  THE  SECOND  INPUT  CARD  HAS  CREDIT  DATA,  IF  THIS  HAS  TO  BE 

*  UPDATED  THEN  THE  DISCRETIONARY  INCOME  CALC  HAS  TO  BE  RUN 

IF  CREDIT-INFO-WS  IS  EQUAL  TO  SPACES 

MOVE  CREDIT-INFO-MAS-OLD  TO  CREDIT- INFO-MAS-NEW 
MOVE  ACCOUNT-INFO— MAS-OLD  TO  ACCOUNT-INFO-MAS-NEW 

ELSE 

PERFORM  C8-CALC-DISCRETNRY- INCOME 
PERFORM  C9-CALC -CREDIT-LIMIT 


MOVE  SEX-WS 
MOVE  MAR ITAL-STATUS-WS 
MOVE  NUMBER-DEPENS-WS 
MOVE  INCOME-HUNDREDS-WS 
MOVE  YEAR5-EMPL0YED-WS 
MOVE  OWN-OR-RENT-W5 
HOVE  MORGACE-OR-RENTAL-WS 
MOVE  OTHER-PAYMENTS-WS 
MOVE  DISCR-INCOME-WS 
MOVE  CREDIT-LIM IT-WS 


TO  SEX-MAS-NEW 
TO  MARITAL-STATUS-MAS-NEW 
TO  NUMBER-DEPENS-MAS-NEW 
TO  INCOME-HUNDREDS-MAS-NEW 
TO  YEARS-EMPLOYED-MAS-NEW 
TO  OWN-OR-RENT-MAS-NEW 
TO  MORGAGE-OR-RENTAL-MAS-NEW 
TO  OTHER-PAYMENTS-MAS-NEW 
TO  DISCR-INCOME-MAS-NEW 
TO  CREDIT-LIMIT-MAS-NEW. 


MOVE  CURRENT-BALANCE-OWING-OLD  TO  CURRENT-BALANCE-OWING-NEW. 
MOVE  SPARE-CHARACTERS-OLD  TO  SPARE-CHARACTERS-NEW. 

C6-LOG-ACTION. 

IF  CHANGE-CODE-WS  -  'CH' 

•  WRITE  OLD  TAPE  RECORD 

•  WRITE  CARD  CONTENTS  4  MESSAGE 

•  WRITE  NEW  TAPE  RECORD 

MOVE  SPACES  TO  CREDIT-MASTER- PRINT-LINE 

MOVE  CREDIT-MASTER-OLD-RECORD  TO  CREDIT-MASTER-OUT 
WRITE  PRINT-LINE-OUT  FROM  CREDIT-MASTER-PRINT-LINE 
AFTER  ADVANCING  3  LINES 

»*•  MOVE  SPACES  TO  UPDATE-RECORD-PRINT-LINE 
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MOVE  APPLICATION-DATA-WSB2  TO  APPLICATION-DATA-OUT 
MOVE  UPDATE-MESSAGE-AREA  TO  MESSAGE-AREA-OUT 
WRITE  PRINT-LIME-OUT  PROM  UPDATE-RECORD-PRINT-LINE 
AfTER  ADVANCING  1  LINES 
MOVE  SPACES  TO  CREDIT-MASTER-PRINT-LINE 
MOVE  CREDIT-MASTER-NEW-RECORD  TO  CREDIT-MASTER-OUT 
WRITE  PRINT-LINE-OUT  PROM  CREDIT-MASTER-PRINT-LINE 
AFTER  ADVANCING  1  LINES 
ELSE  IP  CHANGE-CODE-WS  -  'DE' 

WRITE  OLD  TAPE  RECORD 
WRITE  CARD  CONTENTS  i  MESSAGE 
MOVE  SPACES  TO  CREDIT-MASTER-PRINT-LINE 
MOVE  CREO IT-MASTER-OLD-RECORD  TO  CREDIT-M ASTER-OUT 
WRITE  PRINT-LINE-OUT  PROM  CREDrT-MASTER-PRI NT-LINE 
AFTER  ADVANCING  3  LINES 
MOVE  SPACES  TO  UPDATE-RECORD-PRINT-LINE 
MOVE  APPLICATION-DATA-WSB2  TO  APPLICATION-DATA-OUT 
MOVE  UPDATE-MESSAGE-AREA  TO  MESSAGE-AREA-OUT 
WRITE  PRINT-LINE-OUT  PROM  UPOATE-RECORD-PRINT-LINE 
AFTER  ADVANCING  1  LINES 
ELSE  IP  CHANGE-CODE-WS  -  •  ' 

WRITE  CARDS  FOR  ADDITION 
WRITE  NEW  TAPE  RECORD 
MOVE  SPACES  TO  UPDATE-RECORD-PRINT-LINE 
MOVE  APPLICATION-DATA-WSB2  TO  APPLICATION-DATA-OUT 
MOVE  UPDATE -MESSAGE -AREA  TO  MESSAGE-AREA-OUT 
WRITE  PRINT-LINE-OUT  PROM  UPDATE-RECORD-PRINT-LINE 
AFTER  ADVANCING  3  LINES 
MOVE  SPACES  TO  CREDIT-MASTER-PRINT-LINE 
MOVE  CREDIT-MASTER-NEW-RECORD  TO  CREDIT-MASTER-OUT 
WRITE  PRINT-LINE-OUT  PROM  CREDIT-MASTER-PRINT-LINE 
AFTER  ADVANCING  1  LINES 


•  WRITE  CARD  CONTENTS  t  MESSAGE 
MOVE  APPLICATION-DATA-WSB2  TO  APPLICATION-DATA-OUT 
MOVE  UPDATE-MESSAGt-AREA  TO  MESSAGE-AREA-OUT 

WRITE  PRINT-LINE-OUT  FROM  UPDATE-RECORD-PRINT-LINE 
AFTER  ADVANCING  3  LINES. 

C8-CALC-DISCRETNRY- INCOME. 

COMPUTE  ANNUAL- I NCOME-WS  •  INCOME-HUNDREDS-WS  •  100. 
COMPUTE  ANNUAL-TAX-WS  -  ANNUAL-INCOME-WS  •  TAX-RATE-WS. 
COMPUTE  MONTHLY-NET-INCOME-WS  ROUNDED 

-  (ANNUAL-INCOME-WS  -  ANNUAL-TAX-WS)  /  MONTHS- IN- YEAR. 
COMPUTE  MONTHLY-PAYHENTS-WS  -  MORGAGE-OR-RENTAL-WS 
♦  OTHER-PAYHENTS-WS. 

COMPUTE  D I SCR- I NCOME-WS  •  MONTHLY-NET-INCOME-WS 
-  MONTHLY-PAYHENTS-WS 
OM  SIZE  ERROR  MOVE  999  TO  DISCR-IWCOHE-WS. 

*  DISCRETIONARY  INCOMES  OVER  $999  PER  MONTH  ARE  SET  AT  $999. 


C9-CALC-CREDIT-LIMIT. 

HARRIED? 

OWNED? 

2  OR  MORE  YEARS? 


YYYYNNNN 

YYNNYYNN 

YNYNYNYN 


CREDIT  PACT0R1 
LIMIT  2  XX 

MULTIPLE  3  X 

OP  DISCR.  4  XX 

INCOME  5  X 

If  MAR ITAL-STATUS-WS  •  *M* 

IP  OWN-OR-RENT-WS  •  '0* 


THIS  DECISION  TABLE  • 

SETS  OUT  COMPANY  POLICY  * 
POR  DETERMINING  CREDIT  * 
LIMIT  PROM  DISCRETIONARY* 
INCOME.  FACTOR 1  ETC  ARE  • 

SET  UP  IN  WSC9.  * 

• 


574 

575 

576 

577 

578 

579 

580 

581 

582 

583 

584 

585 

586 

587 

588 

589 

590 

591 

592 

593 

594 

595 

596 

597 

598 

599 

600 
801 
502 
603 
804 
605 
506 

607 

608 

609 

610 
611 
612 

613 

614 

615 

616 

617 

618 
619 


IF  YEARS-EMPLOYED-WS  IS  NOT  LESS  THAN  02 
MOVE  FACTOR5  TO  CREDIT-FACTOR 

ELSE 

MOVE  FACTOR4  TO  CREDIT-rACTOR 

ELSE 

IF  TEARS- EMPLOYED-WS  IS  NOT  LESS  THAN  02 
MOVE  FACTOR 4  TO  CREDIT-FACTOR 

ELSE 

MOVE  FACTOR 2  TO  CREDIT-FACTOR 

ELSE 

IF  OWN-OR-RENT-WS  ■  ’0* 

IF  YEARS-EMPLOYED-WS  IS  NOT  LESS  THAN  02 
MOVE  FACTOR3  TO  CREDIT-FACTOR 

-  ELSE 

MOVE  FACTOR 2  TO  CREDIT-FACTOR 

ELSE 

MOVE  FACTOR 1  TO  CREDIT-FACTOR. 

COMPOTE  CREDIT-LIMIT-WS  •  DISCR-INCOME-WS  *  CREDIT-FACTOR. 
IF  CREDIT-LIMIT-WS  IS  GREATER  THAN  UPPER- LIHIT-WS 
MOVE  UPPER-LIMIT-WS  TO  CREDIT-LIMIT-WS. 

ADD  CREDIT-LIMIT-WS  TO  TOTAL-CREDIT-CIVEN-WS. 


C 1 0-ASSENB LE-NEW-M ASTER-RECORD. 

MOVE  ACCT-NUM-WS  TO  ACCT-NUM-MAS-NEW. 

MOVE  NAME-AND-ADDRESS-WS  TO  NAME-AND-ADDRESS-MAS-NEW. 
MOVE  AREA-CODE-WS  TO  AREA-CODE-MAS-NEW. 


PERFORM  Dl-REMOVE-HYPHEN-FROM-TEL-NUM. 


MOVE  SEX-WS 

MOVE  MARITAL-STATUS-WS 
MOVE  NUMBER-DEPENS-WS 
MOVE  INCOME-HUNDREDS-WS 
MOVE  YEARS-EMPLOYED-WS 
MOVE  OWN-OR-RENT-WS 
MOVE  MORGAGE-0R-RENTAL-WS 
MOVE  OTHER-PAYMENTS-WS 
MOVE  DISCR-INCOME-WS  TO  DISCR-INCOME-MAS-NEW. 
MOVE  CREDIT-LIMIT-WS  TO  CREDIT-LIMIT-MAS-NEW. 
MOVE  ZEROES  TO  CURRENT-BALANCE-OWING-NEW. 

MOVE  SPACES  TO  SPARE-CHARACTERS-NEW. 


TO  SEX-MAS-NEW 
TO  MARITAL-STATUS-MAS-NEW 
TO  NUMBER-DEPEMS-MAS-NEW 
TO  INCOME-HUNDREDS-HAS-NEW 
TO  YEARS-EMPLOYED-MAS-NEW 
TO  OWN-OR-R ENT-MAS-NEW 
TO  MORGAGE-OR -RENTAL-MAS -NEW 
TO  OTHER-PAYMENTS-MAS-NEW. 


Dl-REMOVE-HYPHEN-FROM-TEL-NUM. 

MOVE  NUMBR-WS  TO  TEL-NUMBR-WITH-HYPHEN 

MOVE  EXCHANGE- IN  TO  EXCHANGE 

MOVE  FOUR -DIG IT-NUHBR-IN  TO  FOUR-DIGIT-NUMBR 

MOVE  TEL-NUMBR-WITHOUT-HYPHEN  TO  NUMBR-MAS-NEW. 
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